為多云平臺選擇云配置管理工具
多云模型面臨著獨特的配置管理挑戰。當選擇一個工具時，企業應該仔細對比云本地和第三方的選項。
當企業選擇向云計算遷移時，配置管理并沒有消失。事實上，配置管理在云中變得更加重要——尤其是當企業使用多云提供商時，因為它幫助跟蹤并控制的軟件的變化。
與他們使用本地工具一樣，組織使用云配置管理工具來確保對所需交付服務的資源的適當控制。這些工具還可以提供一些信息，關于如何更好地配置資源 ，以及資源之間的關系的信息。
但企業面臨著一個重要選擇：在公有云中使用本地配置服務，還是使用第三方工具，如Ansible 和CFengine。這一選擇并不簡單。本地云配置管理工具使得企業變得更加依賴于它的公有云提供商，增加了廠商鎖定的風險。例如，當企業使用現兩個或更多的公有云時，如AWS和人體中，本地配置工具在這兩具平臺上的表現可能不會很好。
配置管理選項
來自于第三方和云提供的一些最為常見的云盞管理工具：
第三方：
- Chef
- Puppet
- Terraform
- SmartFrog
- Ansible
提供商自有：
- AWS Config
- Microsoft System Center Configuration Manager
- Google Cloud Platform's autoscaler
- Google Cloud Platform instance groups and managed instance groups
第三方配置工具，無論是否基于云，都可以與多云提供商合作，提供抽象層來移除某些配置復雜性。然而，這些第三方工具在公有云中獲得一些能力時，他們也可能會失去一些能力。為了采用最小公分母方法，第三方云配置管理工具要放棄一些本地工具所提供的能力。例如，許多本地工具提供一種功能來實時更新庫——存儲跟蹤資源相關的數據的系統。
第三方工具經常需要你手動執行這類任務，這將浪費時間，并且增加的錯誤的機率，然而他們可以跨不同的云平臺工作。企業需要折衷一下，來平衡本地云服務的工作能力，如AWS中的功能，與從多云本地服務抽象工具的能力。
例如，AWS OpsWorks是使用了Chef的云配置管理服務。Chef提供了一個自動化的平臺，把服務配置作為代碼看待。組織可以部署這一技術來動態更改他們的軟件配置。這一行為通過程序代碼完成，不是通過GUI完成的。這允許開發人員根據意愿變更配置，使用API從程序中直接更改。AWS OpsWorks能夠自然地與Amazon Elastic Compute Cloud實例合作，但卻不能確保與其它提供商，如谷歌或微軟 Azure的正常運行。
云配置管理需要跨所有相關平臺的高效運行。雖然組織可以使用第三方工具跨不同的云服務，但這些工具不能為每個平臺做所有的事，所以有一些需要人工流程琮完成。現在，是好的選擇是使用多云配置管理工具，即它成本更高，更復雜。
