隨著Docker公司那難以抑制的宏圖壯志的逐漸顯露，其他人關(guān)于未來趨勢的聲音也許值得關(guān)注。
午夜一點(diǎn)，你收到了一封系統(tǒng)自動發(fā)送的來自“應(yīng)用移植經(jīng)理”的郵件，其中講到量控制程序(它本身也是一個容器化形式的應(yīng)用)已經(jīng)自動將你的AWS實(shí)例遷移到了你的新的Google實(shí)例。此外，你所有容器已經(jīng)啟動并運(yùn)行，原有和企業(yè)數(shù)據(jù)庫的連接也已經(jīng)完成重建，同時(shí)所有的安全和管控服務(wù)也已經(jīng)重置成功。
這一切都是自動發(fā)生的，甚至在跨云遷移前你自己都不清楚這樣的遷移即將發(fā)生，而這是系統(tǒng)分別對在AWS和Google上運(yùn)行容器化應(yīng)用的成本差異進(jìn)行對比之后，自動作出的決定。而后者一旦被證明更具成本效益后，基于預(yù)定義規(guī)則的跨云自動移植即可開始，所有容器即可跨公有云遷移。當(dāng)然，同樣也可以是跨私有云遷移或者公有云/私有云之前遷移。
當(dāng)下，這樣的場景也許聽起來更像是科幻小說，但也許不久我們即將具備這種能力。這種能夠?qū)θ萜鬟M(jìn)行混合和配對、自動跨云遷移，并針對不同云完成本地化工作的可能性，也許會改變我們對云計(jì)算的發(fā)展，對公有/私有IAAS和PAAS的一些看法。
發(fā)現(xiàn)新價(jià)值
在如下這樣一個數(shù)據(jù)中心中，它具有云編排層（cloud-orchestration layer），能夠支持容器運(yùn)行、支持容器在線遷移，并能在容器遷移后監(jiān)控其狀態(tài)。使用容器并不算是一件新鮮事，甚至在Docker出現(xiàn)之前人們已經(jīng)在使用各種容器了。但是，“自動資源調(diào)配”和“自動遷移”之前更多仍是停留在概念上，在實(shí)際的實(shí)踐推廣過程中仍然面臨很多困難。Docker的出現(xiàn)為將概念變?yōu)楝F(xiàn)實(shí)提供了更多可能性：
通過容器層的抽象來降低復(fù)雜性
容器屏蔽了對底層基礎(chǔ)設(shè)施服務(wù)的依賴，降低了和這些平臺打交道的復(fù)雜度。容器具有非常明確的定義，即支持應(yīng)用程序或服務(wù)的“小平臺”。
通過自動化，最大化容器的可移植性和容器自身的價(jià)值。
通過自動化，我們可以通過腳本實(shí)現(xiàn)容器的跨云遷移。這意味著需要重新配置容器間的各種通訊，如不同層級間的通訊，同數(shù)據(jù)服務(wù)的通訊。今天，在對應(yīng)用進(jìn)行自動化遷移時(shí)，效果依然很難盡如人意。事實(shí)上，自動化遷移通常需要依賴于很多經(jīng)常變化的外部條件，一旦不再具備這些條件，遷移就會非常困難。盡管這些問題依然存在，但幸運(yùn)的是，這些問題并非不可解決的。
提供更好的安全和治理服務(wù)
通常在許多情況下，安全和治理服務(wù)是基于特定平臺并與其綁定，而不是和特定應(yīng)用程綁定的。通過在容器外圍部署安全和治理服務(wù)，而不是在容器內(nèi)部或者應(yīng)用域(application domain)部署，可以提供更好的移植性，降低遷移操作時(shí)的復(fù)雜度。
提供更好的分布計(jì)算的能力
這主要是因?yàn)閼?yīng)用程序容器化之后可以更容易的分到許多不同的域，而這些域中都是各自容器形式存在的應(yīng)用。這些容器可以以任意數(shù)量運(yùn)行在不同的云平臺，特別是那些提供最優(yōu)性價(jià)比的云平臺。換句話所，就是容器化的應(yīng)用在分布部署時(shí)可以根據(jù)容器對各平臺的利用率進(jìn)行優(yōu)化。比如說：可以將i/o密集型應(yīng)用程序更多在部署在裸機(jī)上，以提供最佳的性能，將一個計(jì)算密集型的應(yīng)用程序更多部署在可以提供適當(dāng)?shù)目s放和負(fù)載平衡的公有云上，甚至可以將其中一部分有選擇地部署在傳統(tǒng)的硬件和軟件。總之，應(yīng)用程序可以被分割為優(yōu)化的組件，而這些組件結(jié)合在一起則構(gòu)成完整的應(yīng)用程序.
回到現(xiàn)實(shí)
雖然可能有其他更好的方式來利用新興的云計(jì)算平臺，并且看起來仍有許多障礙需要克服，但器化仍然可說是分布式應(yīng)用的重大變革。
雖然目前技術(shù)確實(shí)可以管理機(jī)器實(shí)例，甚至基于簡單策略和腳本，已經(jīng)可以實(shí)現(xiàn)策略驅(qū)動(policy-driven)的自動化跨云的容器遷移，包括自動配置、自動本地化，但當(dāng)下的自動化和編排技術(shù)仍然達(dá)不到我們所期望的程度。
此外，Docker推出的時(shí)日尚短，關(guān)于Docker及其所代表的容器虛擬化的潛力和局限性仍需探索。以之前的容器和分布式推廣經(jīng)驗(yàn)來看，這項(xiàng)技術(shù)可以發(fā)揮最大價(jià)值的途徑是提供容器的跨云協(xié)調(diào)(cloud coordination)。是的，能夠成為跨云的標(biāo)準(zhǔn)是一件激動人心事情，但歷史告訴我們，供應(yīng)商和廠商都傾向于在自己的標(biāo)準(zhǔn)和方向上繼續(xù)前進(jìn)，以確保自己的市場份額利益。如果出現(xiàn)這種情況，則一切都會變成空談了。
最后的問題。 雖然我們盡力讓事情簡化，隨著時(shí)間的過去，使用容器作為平臺的一種抽象意味著應(yīng)用程序?qū)⒊訌?fù)雜和更分布的方面變化。未來，你有可能發(fā)現(xiàn)你的應(yīng)用程序運(yùn)行在很多不同的型號和品牌的云平臺的成百上千的容器中。如此復(fù)雜的情況，可能是脆弱并且難以維護(hù)的。
考慮到所有的一切，在云上構(gòu)建應(yīng)用仍然可能是一個較好的選擇。PaaS和IaaS云仍將提供平臺，甚至提供基礎(chǔ)的開發(fā)能力。然而，隨著Docker 商品化的進(jìn)展，應(yīng)用也許會基于容器化的平臺。如果有較大的廠商希望能夠推動容器大規(guī)模推廣、大規(guī)模商用的進(jìn)程，那將會是有趣的一件事情，因?yàn)槌鲇诶娴目紤]，這也很可能是Docker公司自己的方向。
現(xiàn)在的核心問題：如果自管理/自遷移是容器技術(shù)的目標(biāo)，那么對于企業(yè)應(yīng)用基于云平臺的組織而言，是否應(yīng)該重組組織資源以面對新的愿景? 我懷疑大部分組織在云計(jì)算的道路并沒有走到強(qiáng)烈需要容器化的程度，目前的云遷移(cloud migration)工作仍需要繼續(xù)發(fā)展。但是要知道，通過自動化、可遷移的實(shí)現(xiàn)更好的云應(yīng)用架構(gòu)終將是我們的最終目標(biāo)。
博文地址：https://blog.nicescale.com/yun-shang-ying-yong-zi-dong-hua-de-qu-shi-zi-guan-li-zi-qian-yi-de-rong-qi/
京公網(wǎng)安備 11010502049343號