多云往往被吹捧為靈丹妙藥，但實際上它帶來的弊大于利。一個聰明的多云策略才可能會奏效，而且少不了開源。
不乏排隊向你銷售多云管理解決方案的供應商，而這些供應商正是那些排隊向你出售混合云、私有云和幾乎所有跟“云”相關產品的廠商。
這并不是說多云是虛構的。很多組織使用多個云。但對大多數(shù)公司來說，這與某種宏大的戰(zhàn)略無關，相反，正是缺乏戰(zhàn)略才導致運行多個云?；蛘撸鏕artner所說，公司為不同的工作負載選擇不同的云。不管怎樣，這帶來了額外的成本和復雜性。
多云理論上很好
筆者之前的經歷是，一個公司把所有東西幾乎完全建立在一個云上，但是后來要把所有的東西都轉移到另一個云提供商。聽起來很簡單，只需在云X上“關閉”開關，在云Y上“打開”開關。
事實并非如此。開發(fā)人員是在云X上開發(fā)的，因為它有更多的服務和更豐富的功能。當被要求使用云Y構建相同的功能時，他們說：“我們做不到，它沒有我們需要的東西。”隨著時間的推移，一些功能上的缺陷被云Y填補了，但即使是類似的功能，在云提供商之間的部署也往往不同。事實證明，每一個云都提供各種各樣的服務。正如一個深諳Azure的開發(fā)者在Google Cloud或AWS上不會有同樣的效率。
最終保持云X的運行（甚至擴展使用），同時并行運行cloudy。多年過去了，雖然許多服務最終轉移到了云計算，但仍有許多服務保留下來。
正是這段經歷讓筆者感受到：“供應商通過銷售多云來清理環(huán)境，而客戶卻一直被繁復的云策略和天價開支困住。”
多云是“最壞的做法”
這段經歷，以及其他一些經歷，讓筆者贊同達克比爾集團（Duckbill Group）Corey Quinn的看法，他將多云描述為“最差實踐”，而不是“最佳實踐”。
他提出的構建工作負載可以在任何云提供商或自己的數(shù)據(jù)中心之間無縫運行的想法非常有說服力。然而，這實際上就像對開發(fā)人員說“只編寫沒有bug的代碼”一樣，做比說難多了。
因為每一個云都是不同的，有不同的優(yōu)勢和劣勢。無服務器也一樣，AWS上的無服務器服務與Azure或Google Cloud上的不同。如果你想利用谷歌云上的數(shù)據(jù)庫選擇，你猜怎么著？你將無法輕松地將該工作負載移植到任何其他云上。這并不是因為云供應商惡意地鎖定你，而是因為它們都在試圖構建客戶想要使用的有用服務。
同樣的情況是，不管你在不同的云上做了多少不同的服務，你都很難把它們的相關數(shù)據(jù)連根拔起，然后神奇地將這些數(shù)據(jù)移動到其他云上。Gartner分析師Marco Meinardi對此進行了詳細討論：“在云提供商之間移動應用程序的可能性實際上非常低。一旦部署到某一個供應商中，應用程序往往就停留在那里。這是因為數(shù)據(jù)湖很難移植，而且成本高昂。”
什么樣的應用程序在多云世界中工作？正如分析師Kurt Marko所指出的那樣，那些可以高度抽象出來的東西可以讓不同的云變得有趣：“對于最簡單的應用程序，透明的、不被人察覺的工作負載移動只能在’vanilla‘容器平臺上實現(xiàn)。”
開源的作用
筆者不確定多云是不是對大多數(shù)工作負載都有意義，但似乎公司可以在開源領域實現(xiàn)它。
如果一家公司想要最大化自由度/工作負載的可移植性，它可以使用社區(qū)驅動的開源項目，如PostgreSQL或Kubernetes等。盡管這并不適用于所有事情（無服務器計算的一些構建塊已經是開源的，比如一年前的AWS開源Fireracker，而大多數(shù)還沒有），但是對于一些關鍵領域，這可行。
例如，使用PostgreSQL構建的企業(yè)可以選擇在其數(shù)據(jù)中心內自行管理該數(shù)據(jù)庫，或者在任何云上自行管理，或者使用云提供商管理的PostgreSQL服務之一。開源確保了工作負載具有一定的可移植性，以及促使供應商關于這些工作負載的競爭。
公司已經開始購買這些特定于云的服務，并從中獲得真正的價值。這就是為什么多云將與我們同在：不是因為一些宏大的公司戰(zhàn)略，而是因為開發(fā)者會選擇適合他們的?？紤]到開發(fā)人員喜歡開源，使用更多的開源可能是唯一真正聰明的多云策略。
原文鏈接：
Why multicloud is bad strategy,but open source can help-TechRepublic
