這個客戶的優(yōu)勢在于更加接近數(shù)字資產(chǎn)，可以很容易地在數(shù)字生態(tài)系統(tǒng)中保持最新狀態(tài)，允許開發(fā)更高級的最終用戶功能。此外，這個解決方案還應(yīng)與第三方系統(tǒng)和物聯(lián)網(wǎng)傳感器集成，以處理并向用戶提供更多數(shù)據(jù)。從業(yè)務(wù)角度來看，所有這些都是“數(shù)據(jù)是新黃金”的完美理由，然而其時間和預(yù)算都是有限的。
在與這個客戶進行探討之后，Objectivity公司在3個月之后交付了最小可行性產(chǎn)品 (MVP)。在此期間，Objectivity公司組建了一個團隊，了解業(yè)務(wù)領(lǐng)域，創(chuàng)建產(chǎn)品愿景，定義架構(gòu)，并及時交付有效的最小可行性產(chǎn)品 (MVP)以進行商業(yè)化展示。
由于Objectivity公司需要在短時間內(nèi)需要做這么多事情，因此必須設(shè)定正確的優(yōu)先級，并就可接受的限制達成一致。其結(jié)果不只是提供一個原型。Objectivity公司的預(yù)期是，如果潛在客戶在其進行商業(yè)化演示之后希望購買這種產(chǎn)品，應(yīng)該能夠在更短的時間內(nèi)推出該產(chǎn)品。而且要使該項目更具挑戰(zhàn)性，該產(chǎn)品必須與云計算無關(guān)，易于擴展，并且能夠處理多租戶。對于技術(shù)人員來說，這提出了一個重要的問題：為了實現(xiàn)這一目標必須做出什么樣的技術(shù)權(quán)衡?
技術(shù)考慮
在軟件方面，需要以某種方式設(shè)計解決方案，無需太多麻煩即可更改其某些組件。有時客戶會使用這些選項(例如當更改電子商務(wù)的支付服務(wù)提供商時)，有時則不會。很多人也許記得過去的美好時光，因為那時都在為數(shù)據(jù)庫引擎的更改做好準備，但在后來卻很少更改。
懷疑論者可能會想 “供應(yīng)商鎖定風險到底有多大?”，一些人可能還記得谷歌公司在2018年提高了Maps API 14x的價格(在某些情況下)。這證明這種威脅是真實存在的。
那么，這如何適用于云不可知論呢?是否可以簡化云的獨立性?有人說，“云不可知論架構(gòu)是一個誤解”，或者說，“如果人們相信云計算(及其速度)，就不能相信不可知論”。下圖顯示了可用選項的范圍：
在這種情況下，云原生意味著人們可以利用給定云計算提供商的優(yōu)勢(即更好的性能、更好的可擴展性或更低的成本)。
總體而言，企業(yè)對不可知論架構(gòu)的前期投資越多，切換云計算服務(wù)所花費的成本就越少。但是，與此同時，更復(fù)雜和不可知論的設(shè)計將降低生產(chǎn)率，并減緩交付過程。架構(gòu)師面臨著尋找一個令人滿意的最佳解決方案的挑戰(zhàn)，該解決方案既要遵循不可知論，又要遵守商定的時間和預(yù)算范圍。那么如何做到這一點?例如，可以考慮AWS公司的企業(yè)戰(zhàn)略分析師Mark Schwartz建議的轉(zhuǎn)換成本。他建議企業(yè)考慮：
(1)離開云計算提供商的成本;
(2)發(fā)生上述情況的可能性;
(3)減輕云平臺切換風險的成本。
此外，應(yīng)該考慮解決方案的多個方面，例如：
•部署方法;
•托管模式;
•存儲;
•編程語言。
故事還在繼續(xù)
云不可知論的解決方案可能是福也可能是禍——它可以讓企業(yè)為未來的成功做好準備，也可能延遲交付。因此，以下方面在資產(chǎn)管理方案中很重要：
•切換云平臺的成本。企業(yè)可以在微軟Azure云平臺和IBM云平臺上運行一個解決方案，并且無論哪種方式，即使不采用某種形式的云計算提供商退出策略，也都是合理的。
•中小型前期投資?？蛻粝Ｍ苊膺M行大量的前期技術(shù)投資，并且需要了解，在定義新產(chǎn)品時，必須留出一些空間進行功能試驗。
•盡管不可能，但企業(yè)必須在內(nèi)部部署數(shù)據(jù)中心運行做好準備。當時，假設(shè)新產(chǎn)品的潛在企業(yè)客戶可能會對云平臺的安裝設(shè)置這樣的限制。
評估應(yīng)用程序體系結(jié)構(gòu)及其變體的一種方法是使用適應(yīng)性功能。這一概念借鑒了進化計算的思想，用于計算給定設(shè)計與實現(xiàn)給定項目的一組重要目標之間的距離。
因此，假設(shè)在方案中：
架構(gòu)適應(yīng)度=生產(chǎn)力-前期投資-轉(zhuǎn)換成本+內(nèi)部支持
考慮到這一點，考慮采用以下選項：
解決方案
為此選擇一種混合方法，因為它滿足了所有需求。另外，當涉及到新項目中的容器化時，當企業(yè)嘗試避免供應(yīng)商鎖定時，這似乎是一項輕而易舉的事情。大多數(shù)解決方案是在.NET Core中實現(xiàn)的，作為一組運行在托管的Kubernetes集群中的服務(wù)和工作程序。為了不浪費時間配置持久存儲，使用托管PostgreSQL作為所有組件的通用數(shù)據(jù)存儲。Postgres是一個開源數(shù)據(jù)庫，在多個云平臺中作為托管服務(wù)提供，另外它還支持JSON文檔，這是平臺的另一個重要方面。
關(guān)于物聯(lián)網(wǎng)集成，選擇了云原生實施(例如Azure 物聯(lián)網(wǎng)中心)。除了采用更具擴展性的方法外，它的實施速度也要快得多。而且如果需要，可以很容易地將其重寫以在另一個云平臺上工作。容器托管的物聯(lián)網(wǎng)中心的研究結(jié)果表明，沒有任何一種解決方案符合期望，尤其是在支持與傳感器的雙向通信方面。為了進一步降低切換成本，為物聯(lián)網(wǎng)事件定義了規(guī)范的消息格式，以便消息轉(zhuǎn)換發(fā)生在Kubernetes集群之外(例如在Azure功能中)，而其余所有處理都發(fā)生在集群內(nèi)部。
最終結(jié)果
Objectivity公司成功地按時交付了可在Azure云平臺上運行的解決方案，用于為客戶提供的商業(yè)化展示。數(shù)據(jù)存儲的權(quán)衡通過了時間的考驗。Objectivity公司在Azure云平臺和IBM云平臺上進行了一些產(chǎn)品安裝，所有功能都正常。Kubernetes也運作良好。但是需要記住，提供程序之間存在細微差異。例如，Ingress控制器會自動安裝在IBM云平臺上，而使用Azure云平臺則必須自己執(zhí)行此操作。此外，Kubernetes對于每個云計算提供商都具有不同的存儲類別。
在展示幾個月后，Objectivity公司還使用IoT Watson開發(fā)了第二個物聯(lián)網(wǎng)實例，這證明了云原生方法是一個很好的權(quán)衡方案。但是，必須意識到各種排隊實現(xiàn)之間的區(qū)別。使用Azure Service Bus交付新功能確實非常容易，尤其是如果企業(yè)具有.NET背景。但是，切換到RabbitMq后，可能會發(fā)現(xiàn)不支持某些排隊功能，并且在這個階段，客戶將不得不在代碼中實現(xiàn)它們，這引入了不必要的復(fù)雜性。為避免這些挑戰(zhàn)，首先要堅持使用不可知的隊列實現(xiàn)，而不是為了快速交付而選擇已經(jīng)知道的內(nèi)容。
版權(quán)聲明：本文為企業(yè)網(wǎng)D1Net編譯，轉(zhuǎn)載需注明出處為：企業(yè)網(wǎng)D1Net，如果不注明出處，企業(yè)網(wǎng)D1Net將保留追究其法律責任的權(quán)利。
京公網(wǎng)安備 11010502049343號