通常有兩種力量推動圍繞多云的討論：自由選擇組織所需的云計算工具和平臺，以及這些選擇帶來的復雜性。

這并不總是那么容易，但組織有多種方法可以構建IT架構，提供跨環境的一致性并避免供應商鎖定。企業需要遵循獲取有關如何構建多云應用程序并了解何時不值得這樣做的建議。

在構建多云應用程序之前考慮這些因素

無論是發生中斷、價格變化、與供應商的關系破裂，還是其他原因，很多企業都希望構建自己的應用程序，以便在認為合適的時間和地點移動代碼。 

但是，編寫與云計算無關的代碼不僅僅涉及避免使用特定于平臺的工具。以下是構建可在多個云平臺上使用的應用程序時需要記住的四個因素：

1.不要在源代碼中包含密碼和API密鑰等敏感信息。

2.為應用程序提供單一入口點。要***限度地降低故障點風險，使用循環域名系統記錄在云計算提供商之間分配負載。

3.盡可能自動化以最小化復雜性。

4.不要完全排除本機工具。云計算供應商可能擁有真正獨特、有價值的服務，或者避免使用特定工具的成本可能高于供應商鎖定的風險。

考慮何時以及如何規劃可遷移性

組織優化其特定云平臺的工作負載越多，以后移動這些應用程序就越困難。如果IT團隊想要獲得可遷移性，他們需要了解使用的服務的含義以及如何將應用程序錨定到給定平臺。

例如，云計算提供商推動與其競爭對手進行功能奇偶校驗，但這并不一定能夠更輕松地在云平臺之間遷移工作負載。即使兩個提供商具有可比較的服務，它們也通過不同的API提供。開發人員需要重寫組件才能在其他云平臺上工作。

盡管如此，遷移性并不是***的。事實上，從長遠來看，即使成本較高，找到適合工作負載的合適平臺也會更具成本效益。如果企業擁有深度互聯的應用程序，***將它們托管在自己的數據中心內，以限制流量費用、集成和安全問題。 

克服平臺差異

部署多云戰略的組織需要彌補應用程序部署在不同云中的執行方式不同的事實。企業可以通過限制擴展到一個云平臺，在不同的云平臺中運行并行部署或抽象某些組件來實現這一目標。

如果組織使用諸如Apache Meos或Kubernetes之類的軟件將部署同質化，以抽象應用程序平面或使用諸如Ansible、Chef或Puppet之類的DevOps工具，則會采用規模和重新部署方法。

運行并行部署與擴展和重新部署方法類似，但事務和其他任務是共享的。這將需要在重復的應用程序組件之間使用負載均衡器，但不需要特殊的部署技術，因為只有工作在云平臺之間移動。

當應用程序組件需要跨云平臺進行擴展或故障轉移時，IT團隊可以使用基于適配器設計模式的某種私有中間件。這會將不同的云平臺提供程序API拉入單個API，然后開發人員可以使用它。如果提供商的服務不同，則創建更高級別的抽象，以將組織的API映射到每個云中的特定功能。

簡化持續集成和持續交付(CI/CD)管道

與云計算提供商無關的持續集成和持續交付(CI/CD)管道可以簡化多云應用程序的部署過程，如果IT團隊選擇采用這種方式，則可以選擇多種方案。

大多數云計算供應商都支持安全文件傳輸協議。雖然它容易出錯，但開發人員可以使用它來交換、更新或刪除端點，同時保持部署的性質。

IT團隊還可以使用容器來集中應用程序構建，并避免在多個環境中部署整個應用程序代碼。應用程序映像可以保存到任何云都可以訪問的容器存儲庫中，開發人員可以使用給定提供程序的編排工具來啟動應用程序映像。

如果企業仍然想要使用一些云原生服務，還有其他一些技巧可以解決依賴性分發，盡管它們可能會降低可遷移性并增加復雜性。例如，如果只有一個提供商擁有上傳內容交付網絡資產的工具，請確保每次使用該云平臺將內容上傳到該CDN，即使目標是另一個云平臺。

無論采用哪種方法，企業還必須確定將在每個環境中運行的部署后任務，以便平衡云中的負載。同樣，更多的云平臺會增加復雜性，因此請注意應用程序依賴的托管功能以及需要額外管道自制的方式。