對象和圖形數據庫提供商Objectivity公司兩年前為一個客戶構建一個新的數字生態系統。該客戶雖然占有很大的市場份額，但并沒有技術創新或數字悟性。為了解決這個問題，他們提出了構建一個管理資產組合的軟件平臺的計劃。

[[325346]]

這個客戶的優勢在于更加接近數字資產，可以很容易地在數字生態系統中保持最新狀態，允許開發更高級的最終用戶功能。此外，這個解決方案還應與第三方系統和物聯網傳感器集成，以處理并向用戶提供更多數據。從業務角度來看，所有這些都是“數據是新黃金”的完美理由，然而其時間和預算都是有限的。

在與這個客戶進行探討之后，Objectivity公司在3個月之后交付了最小可行性產品 (MVP)。在此期間，Objectivity公司組建了一個團隊，了解業務領域，創建產品愿景，定義架構，并及時交付有效的最小可行性產品 (MVP)以進行商業化展示。

由于Objectivity公司需要在短時間內需要做這么多事情，因此必須設定正確的優先級，并就可接受的限制達成一致。其結果不只是提供一個原型。Objectivity公司的預期是，如果潛在客戶在其進行商業化演示之后希望購買這種產品，應該能夠在更短的時間內推出該產品。而且要使該項目更具挑戰性，該產品必須與云計算無關，易于擴展，并且能夠處理多租戶。對于技術人員來說，這提出了一個重要的問題：為了實現這一目標必須做出什么樣的技術權衡?

技術考慮

在軟件方面，需要以某種方式設計解決方案，無需太多麻煩即可更改其某些組件。有時客戶會使用這些選項(例如當更改電子商務的支付服務提供商時)，有時則不會。很多人也許記得過去的美好時光，因為那時都在為數據庫引擎的更改做好準備，但在后來卻很少更改。

懷疑論者可能會想 “供應商鎖定風險到底有多大?”，一些人可能還記得谷歌公司在2018年提高了Maps API 14x的價格(在某些情況下)。這證明這種威脅是真實存在的。

那么，這如何適用于云不可知論呢?是否可以簡化云的獨立性?有人說，“云不可知論架構是一個誤解”，或者說，“如果人們相信云計算(及其速度)，就不能相信不可知論”。下圖顯示了可用選項的范圍：

在這種情況下，云原生意味著人們可以利用給定云計算提供商的優勢(即更好的性能、更好的可擴展性或更低的成本)。

總體而言，企業對不可知論架構的前期投資越多，切換云計算服務所花費的成本就越少。但是，與此同時，更復雜和不可知論的設計將降低生產率，并減緩交付過程。架構師面臨著尋找一個令人滿意的最佳解決方案的挑戰，該解決方案既要遵循不可知論，又要遵守商定的時間和預算范圍。那么如何做到這一點?例如，可以考慮AWS公司的企業戰略分析師Mark Schwartz建議的轉換成本。他建議企業考慮：

• 離開云計算提供商的成本;
• 發生上述情況的可能性;
• 減輕云平臺切換風險的成本。

此外，應該考慮解決方案的多個方面，例如：

• 部署方法;
• 托管模式;
• 存儲;
• 編程語言。

故事還在繼續

云不可知論的解決方案可能是福也可能是禍——它可以讓企業為未來的成功做好準備，也可能延遲交付。因此，以下方面在資產管理方案中很重要：

• 切換云平臺的成本。企業可以在微軟Azure云平臺和IBM云平臺上運行一個解決方案，并且無論哪種方式，即使不采用某種形式的云計算提供商退出策略，也都是合理的。
• 中小型前期投資。客戶希望避免進行大量的前期技術投資，并且需要了解，在定義新產品時，必須留出一些空間進行功能試驗。
• 盡管不可能，但企業必須在內部部署數據中心運行做好準備。當時，假設新產品的潛在企業客戶可能會對云平臺的安裝設置這樣的限制。

評估應用程序體系結構及其變體的一種方法是使用適應性功能。這一概念借鑒了進化計算的思想，用于計算給定設計與實現給定項目的一組重要目標之間的距離。

因此，假設在方案中：

架構適應度=生產力-前期投資-轉換成本+內部支持

考慮到這一點，考慮采用以下選項： 

解決方案

為此選擇一種混合方法，因為它滿足了所有需求。另外，當涉及到新項目中的容器化時，當企業嘗試避免供應商鎖定時，這似乎是一項輕而易舉的事情。大多數解決方案是在.NET Core中實現的，作為一組運行在托管的Kubernetes集群中的服務和工作程序。為了不浪費時間配置持久存儲，使用托管PostgreSQL作為所有組件的通用數據存儲。Postgres是一個開源數據庫，在多個云平臺中作為托管服務提供，另外它還支持JSON文檔，這是平臺的另一個重要方面。

關于物聯網集成，選擇了云原生實施(例如Azure 物聯網中心)。除了采用更具擴展性的方法外，它的實施速度也要快得多。而且如果需要，可以很容易地將其重寫以在另一個云平臺上工作。容器托管的物聯網中心的研究結果表明，沒有任何一種解決方案符合期望，尤其是在支持與傳感器的雙向通信方面。為了進一步降低切換成本，為物聯網事件定義了規范的消息格式，以便消息轉換發生在Kubernetes集群之外(例如在Azure功能中)，而其余所有處理都發生在集群內部。

最終結果

Objectivity公司成功地按時交付了可在Azure云平臺上運行的解決方案，用于為客戶提供的商業化展示。數據存儲的權衡通過了時間的考驗。Objectivity公司在Azure云平臺和IBM云平臺上進行了一些產品安裝，所有功能都正常。Kubernetes也運作良好。但是需要記住，提供程序之間存在細微差異。例如，Ingress控制器會自動安裝在IBM云平臺上，而使用Azure云平臺則必須自己執行此操作。此外，Kubernetes對于每個云計算提供商都具有不同的存儲類別。

在展示幾個月后，Objectivity公司還使用IoT Watson開發了第二個物聯網實例，這證明了云原生方法是一個很好的權衡方案。但是，必須意識到各種排隊實現之間的區別。使用Azure Service Bus交付新功能確實非常容易，尤其是如果企業具有.NET背景。但是，切換到RabbitMq后，可能會發現不支持某些排隊功能，并且在這個階段，客戶將不得不在代碼中實現它們，這引入了不必要的復雜性。為避免這些挑戰，首先要堅持使用不可知的隊列實現，而不是為了快速交付而選擇已經知道的內容。