多云往往被吹捧為靈丹妙藥，但實際上它帶來的弊大于利。一個聰明的多云策略才可能會奏效，而且少不了開源。
不乏排隊向你銷售多云管理解決方案的供應商，而這些供應商正是那些排隊向你出售混合云、私有云和幾乎所有跟“云”相關產品的廠商。
這并不是說多云是虛構的。很多組織使用多個云。但對大多數公司來說，這與某種宏大的戰(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的看法，他將多云描述為“最差實踐”，而不是“最佳實踐”。
他提出的構建工作負載可以在任何云提供商或自己的數據中心之間無縫運行的想法非常有說服力。然而，這實際上就像對開發(fā)人員說“只編寫沒有bug的代碼”一樣，做比說難多了。
因為每一個云都是不同的，有不同的優(yōu)勢和劣勢。無服務器也一樣，AWS上的無服務器服務與Azure或Google Cloud上的不同。如果你想利用谷歌云上的數據庫選擇，你猜怎么著？你將無法輕松地將該工作負載移植到任何其他云上。這并不是因為云供應商惡意地鎖定你，而是因為它們都在試圖構建客戶想要使用的有用服務。
同樣的情況是，不管你在不同的云上做了多少不同的服務，你都很難把它們的相關數據連根拔起，然后神奇地將這些數據移動到其他云上。Gartner分析師Marco Meinardi對此進行了詳細討論：“在云提供商之間移動應用程序的可能性實際上非常低。一旦部署到某一個供應商中，應用程序往往就停留在那里。這是因為數據湖很難移植，而且成本高昂。”
什么樣的應用程序在多云世界中工作？正如分析師Kurt Marko所指出的那樣，那些可以高度抽象出來的東西可以讓不同的云變得有趣：“對于最簡單的應用程序，透明的、不被人察覺的工作負載移動只能在’vanilla‘容器平臺上實現(xiàn)。”
開源的作用
筆者不確定多云是不是對大多數工作負載都有意義，但似乎公司可以在開源領域實現(xiàn)它。
如果一家公司想要最大化自由度/工作負載的可移植性，它可以使用社區(qū)驅動的開源項目，如PostgreSQL或Kubernetes等。盡管這并不適用于所有事情（無服務器計算的一些構建塊已經是開源的，比如一年前的AWS開源Fireracker，而大多數還沒有），但是對于一些關鍵領域，這可行。
例如，使用PostgreSQL構建的企業(yè)可以選擇在其數據中心內自行管理該數據庫，或者在任何云上自行管理，或者使用云提供商管理的PostgreSQL服務之一。開源確保了工作負載具有一定的可移植性，以及促使供應商關于這些工作負載的競爭。
公司已經開始購買這些特定于云的服務，并從中獲得真正的價值。這就是為什么多云將與我們同在：不是因為一些宏大的公司戰(zhàn)略，而是因為開發(fā)者會選擇適合他們的?？紤]到開發(fā)人員喜歡開源，使用更多的開源可能是唯一真正聰明的多云策略。
原文鏈接：
Why multicloud is bad strategy,but open source can help-TechRepublic
