旅途

一、領域澄清

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

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

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文檔地址：

https://docs.helm.sh/

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