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