2010年10月，OpenStack釋出了第一個版本；上個月，釋出了它的第18個版本Rocky。幾年前氣氛火爆，如今卻冷冷清清。Rocky版本宣佈後，OpenStack群裡也就出現了幾篇簡短的翻譯過來的文章。圈子裡也不時飄出『OpenStack是不是死了？』『誰誰誰又把全部OpenStack替換成Kubernetes了』這種訊息。這到底是為什麼才短短几年卻出現如此轉折呢？作為一個OpenStack使用者，在這篇文章裡，我會從使用者視角，反思在過去的八年裡，它到底走了一條怎樣的路；我也會試著展望從現在起的八年之後，OpenStack會過得好不好，甚至還在不在。 

我們是怎樣的一個使用者？

我們作為HH集團雲平臺團隊的一部分，在集團內搭建瞭如下圖所示的基礎雲平臺：

其主要特徵如下：

• 計算：支援KVM、ESXi 和裸金屬伺服器等三個資源池。

• 網路：採用 Neutron + VLAN + OVS 實現了虛擬網路。

• 儲存：採用 Ceph 和 SAN 實現了塊儲存，採用Ceph實現了物件儲存。

• 區：在兩個城市三個機房部署了3個區域，每個區域內劃分資源池，資源池內再按機架劃分可用區。三個層級都使用者都可見，可按需選擇。另外，我們還嘗試搞過一個小型公有云區域。

• 功能：利用了Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic等元件。

• 管理：採用自研雲管理平臺管理多個區域。

• 容器雲平臺：基於Kubernetes的容器雲平臺執行在自己管理的物理機上。

• 團隊：最多時候8個人的OpenStack研發團隊，3個人的運維團隊。

一些感受：

• 總得來說執行的還蠻好，我們在技術和產品選型、研發、運維等方面都做得不錯，團隊非常給力，研發週期較短，迭代快速。現在它支撐著集團大大小小几百套系統，而且很穩定，運維壓力已經比較小了。在此，我也要感謝並肩戰鬥過的小夥伴們。

• 也出現過一些穩定性問題：比如Neutron VR 偶爾會自動切換（我們還有一個小型公有云環境，採用Neutron + VR + OVS 架構）；KVM虛擬機器偶爾自動重啟甚至宕機等；KVM對windows的支援比較差，偶爾出現莫名其妙的問題，比如磁碟離線、藍屏、無法啟動等。

• 監控元件、日誌元件很不健全，都需要我們自己大改或者從零搭建。

• 除了核心模組，其它模組幾乎都是半拉子工程。以Trove 為例，我們花了不少時間，幾乎重寫了一半的程式碼，也就實現了最基本的資料庫例項的建立和管理功能。

• OpenStack 離公有云需求的差距實在太遠。

OpenStack 的定位和對標到底該是什麼？

  OpenStack社群在2010年提出的原始使命是『提供一個滿足公有云和私有云需求的開源的雲端計算平臺』。那個時候，私有云還沒什麼參照物，因此可以認為最早的時候OpenStack 的使命就是做開源的AWS。這真是一個巨集偉的目標，多麼讓人激動人心啊，甚至搞得VMware和AWS的心裡都泛起了層層漣漪！然而，從2014年起的使用者調查結果看，OpenStack做不了公有云，私有云才是OpenStack的主戰場，因為兩種私有云環境加起來有80%，而公有云的比率在2017年才12%，而且是在不斷萎縮。因此，說OpenStack的實際定位是在私有云，這個毋庸置疑。

企業私有云環境中，VMware 是真正的老大。因此，OpenStack這要做私有云的目標，說好聽點，要向 VMware學習；說難聽點，就是要替代掉VMware。而 VMware vSphere 提供的只是虛擬化環境，因此 OpenStack 對標的物件我認為應該是 『VMware的 虛擬化功能』+『AWS的 Cloud 功能，主要是雲API』。但是，因為一開始 OpenStack 對標的是 AWS，而AWS 是公有云不是私有云，這就導致了後來很多問題的出現，下文會仔細道來。 

 『VMware 虛擬化』+『AWS Cloud 功能』這兩部分中，因為一開始OpenStack 就是對標AWS的，因此 『Cloud』部分應該說做得還是很不錯的，或者說克隆的不錯。這從使用者調查的『為什麼組織會選擇OpenStack？』部分的答案中也能看出來，即開放平臺和API的標準化是第一業務驅動力。 

 那『VMware 虛擬化』對標部分的情況又如何呢？來看一下 VMware vSphere 和 OpenStack 基礎功能的對比：

從上表可以看出，大部分的vSphere 的功能OpenStack都沒有實現，或者只實現了一點。那結果只能是，OpenStack 不具備對 VMware 的替代能力，也就無法驅動使用者去放棄VMware 轉向 OpenStack了。

大帳篷模式的問題到底在哪？

2015年，OpenStack 社群開始使用『大帳篷』模式。該模式把OpenStack專案分成兩大類：核心專案和非核心專案。核心專案只有六個，其餘都是非核心專案。

根據個人理解，我簡單地對這個圖的一些問題做下說明：

1. 六個核心服務發展得確實不錯，但是問題依然不少。

   一方面，如下面2017年4月的使用者調查結果，前幾個核心專案的使用率都超過了90%。另一方面，使用者對核心專案的吐槽一直沒停止過，每年的使用者調查報告中都有好幾頁記錄著使用者的槽點。

2. 不管是對比VMware 還是對比AWS，OpenStack核心服務的範圍都太小了，導致它缺乏了一些必要的功能。我認為至少以下幾個服務需要進入核心服務列表：

• 編排服務Heat：編排服務是雲的基礎性服務之一。一來使用者可以通過編排服務自行建立和銷燬雲資源，二來很多二級服務可以通過提供編排模版的方式來提供給使用者，三來可以與第三方雲管平臺和工具對接，從而培育其生態。

• 監控服務Ceilometer：一個雲生產環境離不開一個強壯的監控服務。到目前為止，Ceilometer 專案都還問題重重，比如規模性問題、效能問題、功能覆蓋問題等。

• 裸機服務 Ironic：裸機在私有云中有很多的應用場景，比如執行資料庫、大資料平臺、容器平臺等。如果OpenStack把Ironic做好了，那這就會成為與VMware相比的一大優勢，同時還能成為一些需要利用裸機的應用的支撐平臺。現在的Ironic專案，實在太重太複雜，與物理網路裝置關聯太深。但是，如果可以像LINUX的kickstart和cobbler一樣，就靈活輕量多了，這個過程比如像vmware裡物理機可以批量部署ESXI，然後把ESXI納管進來，就可以使用VC裡的所有服務，這樣的過程就比較合理了。

• 日誌服務：同監控服務一樣，日誌服務也是雲平臺的一個基礎性服務，如同AWS 的CloudWatch和所有專案都打通了一樣。遺憾的是，到現在為止，OpenStack都沒有一個原生的日誌服務專案。

• 部署服務：部署對私有云很重要。OpenStack需要一個提供象 Mirantis Fuel 這樣的圖形化一鍵部署工具的核心服務。

3. OpenStack社群把過多精力耗費在了一些看起來很有前途，但實際上卻比較雞肋的服務專案中，比如容器服務Magnum、大資料服務 Sahara、資料庫服務 Trove、容器化部署服務Kolla。好吧，我曉得你可能有不同的看法，我不想爭論，還是來看使用者調查報告中的資料吧。

•  一方面，使用者對這些專案很感興趣。我認為至少有三個原因，一來是人們對新事物都有好奇心，二來是OpenStack社群的大力宣揚，三是殷切期望。下面的資料來自201704 使用者調查報告：

• 但是這些服務在實際的生產環境中部署的案例卻非常少，而且是越來越少：

（備註：圖中的數字是百分比）

• 那到底是什麼原因導致這些新服務叫好不叫座呢？我認為有幾個原因：

（1）私有云和公有云對雲平臺需求的差異。

下圖是一個我認為比較典型的私有云環境：

它具有幾個特點：

• 只有底層的物理機管理系統是統一的，而上面的多個平臺是分離的。而公有云上，雲平臺是統一的。

• 平臺是分離的。這可能有幾個原因，一是管理因素，每個平臺往往由不同部門在管理和使用；二是運維因素，把平臺都放在一起，運維團隊搞不定這個單體平臺的運維，必須分而治之；三是技術因素，私有云領域還沒出現象AWS和阿里雲這種能把這幾個平臺納管在一起的統一雲平臺；四是在某些企業裡限於等保和安全的需要，某個大業務需要獨佔資源池。

• 除了基礎雲平臺是在虛擬機器級別實現多租戶外，其它平臺往往只是在管理平臺層面實現了多租戶，或者業務層面自己實現了多租戶，而下面是一個或幾個大的資源池。

私有云環境中和公有云環境中，這些服務（其實應該稱為應用服務，與基礎服務分開來）的建立和管理方式迥然不同。在公有云環境中，因為多租戶需求，雲供應商需要提供這些服務的建立和管理服務，使得使用者自行建立、管理和銷燬這些環境。但是，私有云中，並沒有那麼多需求，需要反覆地建立和銷燬這些服務的執行環境。因此，在OpenStack 中實現容器平臺、大資料平臺的自動化建立和銷燬服務這種需求不那麼強烈，甚至可以認為是偽需求。針對這些新應用，OpenStack的使命首先應該是讓它們在自身平臺上『執行好』，而不是『把執行環境建立好』。

究其原因，我認為這和早期OpenStack的使命有關，因為一開始OpenStack是想做成開源的AWS，自然AWS的服務長什麼樣子，OpenStack的服務就長成什麼樣子。問題是，對於私有云和公有云的區別，OpenStack一直沒有重視，或者沒能力重視，因為參照AWS的各個服務在OpenStack中再實現一套，相對來說是比較容易的。而且，在OpenStack紅火的時候，能開一個新的專案，是多麼榮耀的事情啊，PR稿都會發好多。

那為什麼不應該在這些專案上浪費那麼多時間，或者社群不該帶錯方向呢？

• 還是OpenStack的定位沒有明確和及時糾正。面對這些不斷出現的新應用，OpenStack到底該做什麼？是一門心思搞好自己的一畝三分地，同時滿足它們對自己的需求，實現對它們的良好支撐，還是不管如何都要去插一腿呢？我認為本來應該選擇的是前者，但社群實際上選擇的是後者。

• 這些應用的原生部署工具更好。OpenStack上的對應專案，從一開始就做不好這些應用的環境的建立和管理，隨著這些應用的新版本釋出，差距只會越來越大，到最後只留下一些既沒人維護也沒有使用者的半拉子專案。

• OpenStack 社群中這些專案基本上都是不能進入生產環境的半拉子工程，而且改動成本相當高。以我們使用Trove為例，在修改了幾乎一半的程式碼後，也就實現了基本的資料庫例項建立和管理功能，離實際生產需求還有不小的差距。

• OpenStack 對 AWS 的學習只停留在『形』的表面，而沒有學到『神』。儘管AWS 上有一百多個服務，但是，我們看到的是AWS 紮紮實實地把基礎服務做好。舉幾個例子吧。區塊鏈現在很火是吧，AWS 上目前卻只提供了 CloudFormation 模板讓使用者自己去編排執行區塊鏈的雲資源；Kubernetes 現在也很火是吧，但AWS 卻連管理K8S叢集的介面都不提供。 

那OpenStack 對這些新型應用到底該有什麼樣的態度和做法呢？我認為應該是兩點：

• 以不變應萬變，做好這些新應用的執行基礎架構環境，使得這些服務可以良好地執行在由OpenStack管理的虛擬機器/物理機、網路和儲存中。

• 做好Heat服務，象AWS一樣提供好模版，在使用者需要的時候，管理員使用這些模版把這些環境編排出來，然後交給普通使用者使用即可。 

為什麼OpenStack在青年時期就出現了中年危機呢？ 

我認為有如下幾個原因。當然了，這肯定不是全部。

（1）容器的出現，對OpenStack的衝擊很大。但是，我們也要看到，容器的出現，並沒有使得VMware 和以AWS 為代表的IaaS雲服務商叫苦連天。OpenStack該做的不是去抱怨『既生瑜，何生亮』，而應該是反思為什麼OpenStack沒能做好容器的底層架構。

• 以 AWS 為例，它有兩個容器相關專案，一個是它自研的ECS，這是一個Docker 容器管理服務，容器執行在EC2主機上。另一個是EKS，是一個Kubernetes 執行環境的建立和管理服務。AWS 為了支撐容器，主要做了幾件事情：1. 創造了 amazon-ecs-cni-plugin 專案，使得容器可以很好地執行在VPC 中。2. 打通了使用者許可權，使用者可以使用 AWS 的賬號登入到 Kubernetes 環境中。3. 實現了一套Docker 容器管理服務，以及K8S管理節點。

• 反觀 OpenStack 對容器的支援，它主要做了幾件事情，一是大張旗鼓搞 Magnum 專案，花很大力氣做K8S 環境的編排。另一個是有幾個網路相關的專案，但是好像也沒什麼人在用。

• 結果就是，在OpenStack 環境中，K8S 環境的編排也沒做好（當然了，要不要在私有云中做K8S 叢集的建立和管理，前面有過討論），K8S 在OpenStack 環境中也執行不好（因為針對K8S的網路、儲存都沒怎麼搞好）。所以，我認為，是OpenStack 沒有及時為 K8S 做好支撐，才導致 K8S 和 OpenStack 的分離之勢的。

（2）社群沒規劃和控制好OpenStack的發展方向，在關鍵的發展階段浪費了寶貴的時間和資源。前面講過，OpenStack 社群沒能做好自己的定位，並聚焦於基礎性的核心服務，把底部做結實。相反，就像一個毛頭小夥一樣，年輕時不好好學習苦練內功卻被外面的花花世界吸引，成天不務正業，到了成年時卻發現沒能培養其基本的競爭力。另外，在問題出現的時候，社群沒能做到力挽狂瀾，沒能及時糾正發展方向。

（3）部分OpenStack創業公司太浮躁，沒能做好非常關鍵的產品研發和服務。在高峰時，一些創業公司們追求的是社群的貢獻量，而不管貢獻質量，甚至是刷貢獻量；追求的是使用者數量，不惜以低於成本價的方式，而不管專案能不能做成，使用者會不會滿意；追求的是PR文章和各種炒作，而沒能認真地去做使用者案例。總之，產品和服務沒有做好，使用者對OpenStack的口碑和信心沒有樹立起來。相對地，一些認認真真做產品的公司，其OpenStack雲業務卻發展得很好，這說明OpenStack其實是可以做好的，使用者也是願意用的。

（4）很多客戶，特別是大部分傳統企業，實際上用VMware虛擬化就夠了，不一定需要用雲。公司的運維體系、資源交付體系，以及應用的研發、執行和設計架構，都還是虛擬化時代的那一套，因此VMware支撐現有應用也夠了。這從VMware 財報上其收入繼續增長也能看出來。 因此，讓這些客戶從VMware轉到OpenStack的動力能有多大，其實是個很大的問題。

OpenStack的未來到底會如何呢？

 個人認為OpenStack的未來會有兩條路：

• 一條是OpenStack 只作為KVM虛擬機器和Ceph儲存卷的編排器而會走的路。這條路走下去，它會免不了走到和CloudStack這樣的開源雲平臺同樣的結局，那就是還未真正興起就開始真正凋零。

• 另一條是OpenStack走AWS甚至VMware的道路，成為基礎雲、原生雲和未來Serverless雲的支撐平臺。這種情況下，它的路會很長。

但是，遺憾的是，從現在的情況看，OpenStack應該是走在第一條路上，也許這就是很多人認為OpenStack快死掉了甚至已經死掉了的原因吧。 

我對OpenStack的感情 

我對OpenStack有著挺深的感情。是它，讓我認識了什麼是雲，雲是怎麼構建的、是如何執行的、是如何維護的等等。是從研究它開始，我開始從傳統軟體領域進入了雲領域，我也開始了寫部落格的漫漫歷程，也通過它結識了很多朋友。因此，當看到有人故意詆譭它，甚至對它落井下石時，心裡很不是滋味。其實，我覺得不光是我，整個IT領域都應該感謝OpenStack，它的出現大大加速了IT架構演進程序。

前面的內容，也許噴的成分居多，但是，請理解我的心情，因為本來OpenStack是可以發展得更好的，畢竟它曾經擁有過多麼好的天時、地利和人和啊。從實際情況來看，如果企業有一個OpenStack研發團隊，或者找了一個靠譜的外部供應商，而且規模不是特別大，業務不是那麼複雜，還有幾個給力的運維，OpenStack私有云還是可以跑得挺好的。至少在國內，OpenStack已經成為了自主可控的私有云雲平臺的主要代表之一，在各行各業發光發熱。

不管它的結局如何，OpenStack都將在IT發展史上留下了濃墨重彩的一筆。 在此，我想感謝OpenStack專案、感謝OpenStack每一行程式碼和每一個文件、OpenStack社群，和所有給OpenStack做過貢獻的公司和人們。

謝謝您的閱讀，歡迎關注我的個人公眾號：

在我的微信公眾號上發表文章後，一天之後的閱讀情況如下：

所以也慶祝一下本人第一篇閱讀過萬的公眾號文章。：）

再對比一下在部落格園的閱讀量和點贊數，我有幾點感受：

• 網站式部落格在公眾號面前的競爭力已經很弱了。移動端的閱讀量已經佔據絕大多數。
• 部落格園的文章更多聚焦前端技術，以及較傳統的軟體開發技術，比如.Net 這種。
• 微信公眾號粉絲人數因為這篇文章增長了800多人，而部落格園上粉絲只增加了2人。
• 部落格園的運營模式也許在新形勢下需要有重新思考了。