多云模式在正在得到業(yè)界的認可，即公司會從多個云供應商那里獲得不同的IT服務，而同時又會保留一部分自身本地部署的IT工作。不過當公司意識到將工作從一個云轉移到另一個的過程并不像供應商所承諾的那般順利時，各種多云模式的問題也會接踵而來。

不過在進行更深一步討論前，我們有必要對多云模式先做下說明。

[[210207]]

多云的定義

在過去的一兩年內，多云的概念現(xiàn)在了IT行業(yè)中，其大致是指一種公司不僅使用一個到數(shù)個SaaS服務(如人力資源或郵件服務等)并同時使用PaaS服務進行軟件開發(fā)，而且還有可能使用IaaS服務進行虛擬機上工作運行的模式。

Gartner技術和服務供應商研究部門研究總監(jiān)Mattew Cheung表示，“我們看見更多的客戶在同時應用多個公有云服務，因為某些云供應商在特定的工作負載方面具有更加專業(yè)化的能力”。

這些專業(yè)化的服務包括很多關鍵的企業(yè)應用，比如Microsoft Azure中的SQL服務器，Google Cloud中的人工智能(AI)和數(shù)據(jù)分析服務。而像AWS這樣的巨頭也具有眾多的特定的功能和服務，而且每年還在不斷地推新。

“混搭”的云方案

在上云的早期階段中，很多公司會通過“升級和轉移”的方式進行IaaS服務的使用，以實現(xiàn)將工作負載從本地模式中移出。這種模式往往是公司配置虛擬機以取代傳統(tǒng)服務器，實際上是在云的架構中對本地部署的環(huán)境進行了復制。

無論是無意還是有意為之，很多公司都會在多個IaaS平臺上進行工作的部署。這可能是因為數(shù)據(jù)主權、反綁定或冗余問題。

那些兜售混合云產(chǎn)品和服務的供應商會承諾這些都不是問題，當用戶發(fā)現(xiàn)更好的云服務或引入其他公司所需要的新功能或服務時，工作可以很輕易地從一朵云轉移到另一朵云中。

但是，如果公司覺得要上的那朵云并不適合自己工作負載時，遷移的工作還會這么容易嗎?混合云方案的供應商總是試圖讓人們相信遷移的工作就像復制粘貼一樣簡單，但實際上這一過程中困難重重。

擊破多云模式的神話

首先，不同供應商的服務器實例(數(shù)據(jù)庫)的特性可能會截然不用，而且盡管具有像打包和虛擬機映像這樣開放格式的服務，但它們在實踐中卻很少使用。另外，傳統(tǒng)的三層模式的應用通常需要進行單獨服務器集群上的數(shù)據(jù)庫的訪問，這也讓遷移工作變得更加復雜。這就說明，如果我們想要將工作從云端遷移到另一個云端，那么虛擬機并不是一個很理想的選擇。

當然，公司還有一個選擇, 容器。自從Docker技術及其同名平臺出現(xiàn)以來，容器為開發(fā)人員提供了一種簡單的應用程序代碼的封裝方式，并允許人們進行發(fā)布以供本地或云端的運行。

相較于虛擬機，容器具有很強的便攜性優(yōu)勢。容器的大小通常只有數(shù)十兆字節(jié)，而虛擬機會包含整個操作系統(tǒng)以及應用程序，一般會有幾千兆字節(jié)。

總的來說，容器實際上是一種Linux技術(除了最近推出的Windows容器之外), 其主要應用于運行那些在公有云上所謂本地部署的工作負載，而不是那些如今在公司所有系統(tǒng)中運行的傳統(tǒng)企業(yè)應用程序。

相比于虛擬機，目前容器技術更加不成熟，因此其整個生態(tài)正在迅速的構建中，而圍繞著安全性、高可用性以及關鍵資源容器廠商也提供著很多不同的方案。

不過，根據(jù)Cheung所述，即使在這種情況下，簡單地從一個云中提取工作負載并將其轉移到另一個云中的可能性依然很低，因為人們并不看好工作負載會很完美地運行在虛擬機或容器上。相反，人們傾向于依靠其他的功能和服務。由于不同云平臺之間的差異相當明顯，所以很難簡單地將工作負載轉移到不同的云上，除非該工作負載非常簡單和獨立。“今天，在不同公有云之間轉移工作負載真的非常困難”，Cheug說道。

Red Hat的OpenShift平臺就是一個很典型的案例，其使得用戶可以使用Docker及容器以構建和部署應用程序，而且其不僅允許用戶進行本地的部署，而且還支持在Microsoft Azure、AWS和Google云平臺上面的工作部署。 理論上，OpenShift應該可以允許用戶在這些平臺間進行任意應用程序代碼的轉移。 不過，這依然具有依賴性的問題。如果用戶的應用依賴于某一的云平臺特定的功能或服務，那么他們就很難將這些應用遷移到其他平臺中。而且這同時也阻礙了用戶去使用一個更為方便的功能或服務，因為供應商鎖定的問題會讓其無功而返。

無服務器計算的空頭支票

除了PaaS服務外，公司還可以關注下所謂的無服務器計算，這是一種以應用程序按使用次數(shù)而計費的模式，即“功能即服務”或“FaaS”。AWS中的Lambda就是其中的一個例子。

幾乎所有的無服務器平臺都支持Python語言，因此使用該語言編寫的應用程序可以較為容易地實現(xiàn)在不同無服務器平臺上面的遷移。不過當不同的云支持不同的功能時，問題會再次出現(xiàn)，除非有一種通用的代碼，而且公司能夠避免鏈接到任何云特定的功能或服務，否則遷移的過程就不會是無縫的。

實現(xiàn)云端可移植性承諾的另一個障礙來自于實際數(shù)據(jù)。由于合規(guī)性或監(jiān)管的原因，將某些類型的信息遷移出本地基本不可能實現(xiàn)。

另外，由于數(shù)據(jù)中心所在的位置，或者由于只有有限數(shù)量的供應商能夠達到運行特定工作負載所需的認證級別，所以在進行其他云供應商平臺選擇時，公司也會遇到很大的問題。

更重要的是，所涉及到的數(shù)據(jù)量也可能會成為一個問題。當然今天的用戶可以享受到相對較快的互聯(lián)網(wǎng)連接速度，但是由于種種的限制(如網(wǎng)絡攻擊、地理位置、網(wǎng)絡穩(wěn)定性等)，通過互聯(lián)網(wǎng)傳輸數(shù)據(jù)的過程可能會耗費數(shù)天甚至更多的時間。

將數(shù)據(jù)從本地遷移到云端的工作可以通過基于磁盤的設備來完成，只需要將相應的設備運送到云供應商的數(shù)據(jù)中心中，比如AWS的Snowball就是這樣的解決方案。 但是將數(shù)據(jù)從一個云平臺轉移到另一個云平臺的過程不可能這么容易，因為不同的云服務商使用不同的API和數(shù)據(jù)存儲標準，在數(shù)據(jù)提取與傳輸中這會造成很大的障礙。而同時云供應商間不同的定價模式也可能會增加用戶提取與傳輸數(shù)據(jù)的成本。

公司依然需要小心謹慎

由于以上的種種問題，相應的跨平臺的云管理工具仍然不成熟，Gartner在最近一份報告中將其描述為“新興且高度分散的市場”。

云計算和基礎架構的供應商都具有自己的管理工具，但主要集中在如何與自己體系內的軟件進行集成，他們讓第三方的供應商提供某種形式的可支持多云的服務。這種情況使得用戶的IT部門不得不掌握一系列“最佳”的管理工具以監(jiān)管他們的多云環(huán)境，或者使用一種具有有限功能的跨平臺管理工具。

就目前而言，云平臺之間的工作負載與數(shù)據(jù)的移動性依然是一個很重要的問題，盡管容器等技術正試圖攻克這一難關。因此，公司在制定云策略時應該保持謹慎與小心，因為如果決定使用不同的云服務，那么在不同云服務商之間進行工作負載的轉移可能會相當困難而且代價高昂。