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