一、領域澄清

首先明確我們在講什麼，也就是本文描述的應用編排，資源編排是什麼東西。

在雲上編排的含義一般有兩種：

1.雲平臺上自動化建立雲服務，並部署應用。叫做資源編排or應用編排or服務編排。

2. 容器應用，根據資源要求，排程到哪個節點上。叫做容器編排or資源排程。

本文描述範圍，為第1種。

二、公有云編排服務介紹

AWS Cloudformation

Cloudformation文件地址：

AWS的Cloudformation基本屬於雲上自動化（編排）這個領域的領頭羊，功能完備，支援的自動化場景豐富。

在整體生態打造的也很成功，Cloudformation模板，與ServiceCatalog服務目錄，與Marketplace應用市場，一條線從上到下都打通了。

谷歌CDM：（CloudDeployment Manager）

谷歌CDM文件地址：

使用Jinja2語法（Yaml類）和Python語法，實現較為討巧。大部分操作，主推通過命令列完成。雖然控制檯介面也有，但功能主要在命令列裡（意思是介面比較low）。

谷歌CDM支援編排資源列表：

微軟Azure-RM：（ResourceManager）

Azure-RM文件地址：

使用Json語法。且整體模板語法偏複雜，使用門檻比較其他家的還高一點。

有兩個比較有特點的功能：

1.支援根據使用者已經在Azure上建立好的資源資訊，匯出模板。實現類似的“備份”or“快照”的功能。

2.支援任意物件，指定重複建立次數。實現批量複製的能力。

Azure-RM編排提供的內建函式非常豐富：

阿里ROS

ROS文件地址：

整體能力跟隨AWS Cloudformation，但是還略有距離。視覺化模板編輯器，目前並不是很穩定，使用體驗一般。

ROS支援編排的資源列表：

OpenStack Heat

Heat文件地址：

整體能力跟隨AWS Cloudformation，搞了一些Cloudformation語法相容的活，連cfn-tools都照著AWS來。但是目前還略有距離。

也沒有圖形化設計器。

Heat可以編排的資源列表：

華為

AOS文件地址：

使用以應用視角為中心的編排，支援Kubernetes叢集中的物件編排，並圍繞應用支援編排基礎資源+服務。與AWS的Cloudformation相比，發力角度從虛機應用轉向容器應用。

圖形化的模板設計器，體驗很好。特別是智慧輔助對於編寫模板確實很便捷。可以稱作領域標杆。

AOS支援編排物件列表：

K8S Helm

Helm文件地址：

Helm其實自己定位並不是編排，而是一個K8S的manifest包管理工具。不過它有自動化部署K8S物件的能力，所以加入比較。

特點是隻認識K8S叢集裡面的物件，基礎的雲服務不支援編排。使用範圍有限。

青雲RO

RO（Resources Orchestration）文件地址：

青雲的資源編排特點是，不開放模板語法，只提供圖形化設計器。

並且這個圖形化設計器體驗還不錯，有所見即所得的感覺。

但是由於沒有開放模板語法，只靠圖形化設計器，複雜場景編排能力不足。

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生態一環。