很多企業制定了多云備份策略，但這并不意味著應該這樣做。企業需要權衡這種方法帶來的挑戰和潛在收益。
如果企業希望將其備份策略擴展到云端，則多云災難恢復可能不是首選。云計算或私有數據中心發生故障的風險是引起多云架構關注的主要因素。雖然一般來說，數據備份是一種降低風險的行之有效的策略，但有時它可能帶來比解決方案更多的問題。企業管理員需要權衡風險，并詢問自己多云災難恢復計劃是否適合其工作負載。
故障注意事項
關于復雜系統的可靠性，有一個簡單的經驗法則：如果兩個元素可以執行相同的任務，則它們可以互相備份。這降低了故障的綜合風險。相反，如果兩個要素都必須積極工作才能使復雜的系統正確運行，則發生故障的風險會更高。
因此，要使兩個云平臺比一個云平臺更可靠，每個云平臺必須是一個獨立的資源池，能夠支持針對備份的應用程序。對于選擇多云災難恢復策略的組織來說，這會深刻影響架構選擇、成本和其他因素。
此外，企業不太需要多云提供的災難恢復冗余服務，因為單個故障導致數據中心和云計算癱瘓或中斷的可能性非常小。減輕風險的一種更簡單的方法是使用一個云平臺進行備份，并在整個可用區域中分配。然后，構建混合云體系結構(云計算災難恢復的首選方法)的企業可以使其數據中心和云計算環境相互備份。
幸運的是，無論架構師為混合云災難恢復還是多云災難恢復而構建，應用程序更改和云計算服務選擇都基本相同。
為了使用多云災難恢復，企業需要能夠跨邊界(包括跨云平臺和本地數據中心)無縫移動工作負載。必須將應用程序構建為可在任何地方運行，并且運營團隊需要將所有托管資源視為一個資源池。對這兩種做法的任何限制都會減少多云災難恢復的好處并增加成本。
企業還需要考慮公共云服務的兩個級別以及每個級別對多云備份策略的影響：
•IaaS托管。云計算提供商在不同地理位置為虛擬機提供每個虛擬機不同的資源和不同的服務級別協議。盡管云計算提供商的運營實踐通常有所不同，但適應這些差異并不復雜。
•增強Web服務的托管。企業通過一組API使用高級功能。通常，由于功能和編程方面的差異，必須為每個云平臺自定義使用Web服務的應用程序。這使開發負擔加倍，也可能增加許可和運營成本。
容器和微服務
如果將每個云平臺為多云計劃的一部分進行單獨管理，則在沒有人工干預的情況下，很難在環境之間進行故障轉移。
企業有兩種選擇可以緩解這個問題。首先是放棄云計算提供商的運營工具。例如，放棄托管的Kubernetes，轉而使用Red Hat OpenShift或VMware vSphere等工具從數據中心運行Kubernetes生態系統。另一個選擇是通過聯合方法將企業的云計算提供商托管服務與諸如Google Cloud Anthos或IBM的Kabanero之類的工具連接起來。
使用微服務和服務網格(例如Istio或Linkerd)構建支持多云的應用程序更加容易。但是，這種方法要求軟件重建對于某些組織來說可能是一個巨大的飛躍。如果企業選擇這種方法，則需要將服務網格與操作工具集成在一起。服務網格包括跨云分布的組件發現以及工作負載平衡。
成本要求
企業必須權衡多云災難恢復的成本和它將增加的可靠性。不幸的是，幾乎不可能對這些因素進行精確的分析，因為為多云災難恢復準備應用程序的成本取決于所涉及的應用程序數量及其設計方式。
與彈性應用程序部署和重新部署相關的成本取決于這些相同的因素，而企業的操作實踐決定了恢復對問題的響應速度，這是獲得可靠性的重要因素。
不管可靠性如何，多云災難恢復無疑將增加托管成本。如果企業的備份資源無法將工作從另一個發生故障的托管點轉移到災難恢復中，則沒有任何價值，因此企業將必須在每個云中保留一些容量以支持任何故障轉移。這可能會使企業的云計算托管成本增加至少25%，并且如果企業所有的應用程序都無法忍受很少的停機時間，甚至可能會使成本翻倍。
唯一的例外是無服務器。由于它遵循按使用付費的定價模式，因此無論企業的組件運行哪種云平臺，其費用都趨于相同。但是需要記住，無服務器可能是一個更昂貴的托管選項，特別是對于需要經常運行的應用程序，并且它需要更專業的應用程序設計。
多云不只是災難恢復
對于大多數企業來說，多云發現可能不會帶來回報，但這并不意味著使用多云是一個壞主意。許多企業依靠多云技術為全球運營提供有效的云計算服務定位。有些應用程序需要特殊功能，而不是由所有云計算提供商提供，因此它們最終會為不同的應用程序使用不同的云平臺。
規劃多云意味著企業正在為任何云平臺做好準備。始終保持選擇的開放是明智之舉，尤其是在公共云提供商的格局不斷發生變化的情況下。
