一、領域澄清
首先明確我們在講什么，也就是本文描述的應用編排，資源編排是什么東西。
在雲上編排的含義一般有兩種：
1.雲平台上自動化創建雲服務，並部署應用。叫做資源編排or應用編排or服務編排。
2. 容器應用，根據資源要求，調度到哪個節點上。叫做容器編排or資源調度。
本文描述范圍，為第1種。
二、公有雲編排服務介紹
AWS Cloudformation
Cloudformation文檔地址：
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html
AWS的Cloudformation基本屬於雲上自動化（編排）這個領域的領頭羊，功能完備，支持的自動化場景豐富。
在整體生態打造的也很成功，Cloudformation模板，與ServiceCatalog服務目錄，與Marketplace應用市場，一條線從上到下都打通了。
谷歌CDM：（CloudDeployment Manager）
谷歌CDM文檔地址：
https://cloud.google.com/deployment-manager/docs/
使用Jinja2語法（Yaml類）和Python語法，實現較為討巧。大部分操作，主推通過命令行完成。雖然控制台界面也有，但功能主要在命令行里（意思是界面比較low）。
谷歌CDM支持編排資源列表：
https://cloud.google.com/deployment-manager/docs/configuration/supported-resource-types
微軟Azure-RM：（ResourceManager）
Azure-RM文檔地址：
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview
使用Json語法。且整體模板語法偏復雜，使用門檻比較其他家的還高一點。
有兩個比較有特點的功能：
1.支持根據用戶已經在Azure上創建好的資源信息，導出模板。實現類似的“備份”or“快照”的功能。
2.支持任意對象，指定重復創建次數。實現批量復制的能力。
Azure-RM編排提供的內置函數非常豐富：
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-functions
阿里ROS
ROS文檔地址：
https://www.alibabacloud.com/help/zh/doc-detail/28852.htm
整體能力跟隨AWS Cloudformation，但是還略有距離。可視化模板編輯器，目前並不是很穩定，使用體驗一般。
ROS支持編排的資源列表：
https://www.alibabacloud.com/help/zh/doc-detail/48893.htm
OpenStack Heat
Heat文檔地址：
https://docs.openstack.org/heat/latest/template_guide/hot_spec.html
整體能力跟隨AWS Cloudformation，搞了一些Cloudformation語法兼容的活，連cfn-tools都照着AWS來。但是目前還略有距離。
也沒有圖形化設計器。
Heat可以編排的資源列表：
https://docs.openstack.org/heat/latest/template_guide/openstack.html#
華為AOS
AOS文檔地址：
https://support.huaweicloud.com/usermanual-aos/aos_01_0000.html
使用以應用視角為中心的編排，支持Kubernetes集群中的對象編排，並圍繞應用支持編排基礎資源+服務。與AWS的Cloudformation相比，發力角度從虛機應用轉向容器應用。
圖形化的模板設計器，體驗很好。特別是智能輔助對於編寫模板確實很便捷。可以稱作領域標桿。
AOS支持編排對象列表：
https://support.huaweicloud.com/tr-aos/aos_01_4013.html
K8S Helm
Helm文檔地址：
Helm其實自己定位並不是編排，而是一個K8S的manifest包管理工具。不過它有自動化部署K8S對象的能力，所以加入比較。
特點是只認識K8S集群里面的對象，基礎的雲服務不支持編排。使用范圍有限。
青雲RO
RO（Resources Orchestration）文檔地址：
https://docs.qingcloud.com/product/operation/topology
青雲的資源編排特點是，不開放模板語法，只提供圖形化設計器。
並且這個圖形化設計器體驗還不錯，有所見即所得的感覺。
但是由於沒有開放模板語法，只靠圖形化設計器，復雜場景編排能力不足。
RedHat Ansible
Red Hat在2015年收購Ansible，並用在OpenShift里面作為編排服務。
Ansible定位是基於虛機的自動化運維管理工具，類似的系統還有Chef和Puppet。不過Ansible的特點是無需在目標機器上安裝Agent，僅使用SSH遠程執行命令就可以完成目標機器的軟件安裝配置，所以很容易在已有環境中使用。它的本質上是一個工具，而不是一個服務，因為它使用本地目錄+文件的方式來管理“模板”。
語法使用Yaml語言，可以和Jinja2配合，方便表達出復雜的邏輯。
不過Ansible只支持任務按順序單個依次執行，也就是無法設置復雜的有向無環圖（DAG）依賴關系。
所以對流程的編排能力弱了點，但好在支持的對象數量非常豐富，有超過400多種插件。
騰訊無
雲上自動化能力是一個雲平台的剛需，這里一首涼涼送給騰訊雲。。。
三、公有雲編排服務對比
我們直接給出分析結果，省去啰嗦的文字。（文字時效原因，如果有不正確的，及時聯系更正哈）
編排能力對比
√表示“強/做得好”，O表示“一般/待增強”，X表示“沒有此特性”。
設計器能力對比
√表示“強/做得好”，O表示“一般/待增強”，X表示“沒有此特性”。
一張圖對比
四、總結
亞馬遜CFN與阿里ROS
阿里的ROS的定位與AWS的CFN是一致的，功能上也是瞄着CFN追趕。當前情況為：ROS在虛機應用的支持能力遠不及AWS-CFN。不過這個cfn-tools也是AWS的殺手鐧，各大雲廠商都沒有。只有Heat做了一些努力去兼容。
ROS的設計器能力需要增強。目前功能較弱，且在使用中有偶現異常。
亞馬遜CFN與華為AOS
從功能&語法層面，CFN與AOS基本屬於第一陣營，各自互有領先。比如AOS在設計器上領先CFN。不過CFN在虛機應用，及復雜多服務組合場景下，領先AOS。所以AOS需要在后續用更多的場景去進一步催熟。
阿里ROS與華為AOS
ROS在虛機應用部署，及可編排服務的多樣性上優於AOS。而AOS在容器應用相關的能力上優於ROS。圖形化模板編輯器能力則是AOS大幅度領先。
青雲
設計器所見即所得的方式，大幅降低使用門檻，用戶體驗很好。建議將模板語法盡快開放出來，因為編排僅靠圖形化設計器，支持的場景有限。
騰訊雲
雲平台上居然沒有編排服務，畢竟目前為止，所有公有雲都有的剛需服務。希望騰訊雲的技術專家回家好好反省，並盡快補齊這個必備的能力。（比如挖一些華為AOS的專家，你看天下武功出少林，中國容器看華為，都一家人嘛）
微軟Azure
微軟的模板使用Json語法，函數的使用是混雜在Json內部，並不像aws-cfn那么簡潔，整體體驗並不好。感覺把復雜度都提高了很多。
當然，天然的Visual Studio編輯器支持，是編寫模板一個便捷之處。Infrastructureas Code嘛，寫代碼當然有好的IDE才行。
谷歌CDM
CDM（CloudDeployment Manager）使用了jinja2和Python作為模板語法，使得模板覆蓋復雜場景的能力大大增強，算一種優勢吧。
然而沒有合適的UI界面，我想你太不懂國人了。
Helm
語法層面的能力OK，足夠支撐在單個K8S集群中，各種k8s對象的復雜編排場景。自身定位為K8S上的管理工具，一般不作為公有雲獨立服務，僅為容器服務的附屬功能。
沒有圖形化設計器，也不能將基礎資源與K8S對象混合編排。目前進入CNCF的孵化項目，作為K8S生態一環。
OpenStack Heat
定位是與AWS的Cloudformation一致的，實際編排能力與效果與ROS相似，也就是與CFN還有些差距。根據CFN語法和能力做了很多兼容工作。
沒有圖形化設計器，主要側重OpneStack對象or生態的編排，其他服務支持一般。屬於OpenStack生態一環。