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

我們是怎樣的一個用戶？

我們作為HH集團云平臺團隊的一部分，在集團內(nèi)搭建了如下圖所示的基礎云平臺：

其主要特征如下：

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

• 網(wǎng)絡：采用 Neutron VLAN OVS 實現(xiàn)了虛擬網(wǎng)絡。

• 存儲：采用 Ceph 和 SAN 實現(xiàn)了塊存儲，采用Ceph實現(xiàn)了對象存儲。

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

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

• 管理：采用自研云管理平臺管理多個區(qū)域。

• 容器云平臺：基于Kubernetes的容器云平臺運行在自己管理的物理機上。

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

一些感受：

• 總得來說運行的還蠻好，我們在技術和產(chǎn)品選型、研發(fā)、運維等方面都做得不錯，團隊非常給力，研發(fā)周期較短，迭代快速?，F(xiàn)在它支撐著集團大大小小幾百套系統(tǒng)，而且很穩(wěn)定，運維壓力已經(jīng)比較小了。在此，我也要感謝并肩戰(zhàn)斗過的小伙伴們。

• 也出現(xiàn)過一些穩(wěn)定性問題：比如Neutron VR 偶爾會自動切換（我們還有一個小型公有云環(huán)境，采用Neutron VR OVS 架構）；KVM虛擬機偶爾自動重啟甚至宕機等；KVM對windows的支持比較差，偶爾出現(xiàn)莫名其妙的問題，比如磁盤脫機、藍屏、無法啟動等。

• 監(jiān)控組件、日志組件很不健全，都需要我們自己大改或者從零搭建。

• 除了核心模塊，其它模塊幾乎都是半拉子工程。以Trove 為例，我們花了不少時間，幾乎重寫了一半的代碼，也就實現(xiàn)了最基本的數(shù)據(jù)庫實例的創(chuàng)建和管理功能。

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

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

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

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

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

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

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

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

2015年，OpenStack 社區(qū)開始使用『大帳篷』模式。該模式把OpenStack項目分成兩大類：核心項目和非核心項目。核心項目只有六個，其余都是非核心項目。

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

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

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

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

• 編排服務Heat：編排服務是云的基礎性服務之一。一來用戶可以通過編排服務自行創(chuàng)建和銷毀云資源，二來很多二級服務可以通過提供編排模版的方式來提供給用戶，三來可以與第三方云管平臺和工具對接，從而培育其生態(tài)。

• 監(jiān)控服務Ceilometer：一個云生產(chǎn)環(huán)境離不開一個強壯的監(jiān)控服務。到目前為止，Ceilometer 項目都還問題重重，比如規(guī)模性問題、性能問題、功能覆蓋問題等。

• 裸機服務 Ironic：裸機在私有云中有很多的應用場景，比如運行數(shù)據(jù)庫、大數(shù)據(jù)平臺、容器平臺等。如果OpenStack把Ironic做好了，那這就會成為與VMware相比的一大優(yōu)勢，同時還能成為一些需要利用裸機的應用的支撐平臺?，F(xiàn)在的Ironic項目，實在太重太復雜，與物理網(wǎng)絡設備關聯(lián)太深。但是，如果可以像LINUX的kickstart和cobbler一樣，就靈活輕量多了，這個過程比如像vmware里物理機可以批量部署ESXI，然后把ESXI納管進來，就可以使用VC里的所有服務，這樣的過程就比較合理了。

• 日志服務：同監(jiān)控服務一樣，日志服務也是云平臺的一個基礎性服務，如同AWS 的CloudWatch和所有項目都打通了一樣。遺憾的是，到現(xiàn)在為止，OpenStack都沒有一個原生的日志服務項目。

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

3. OpenStack社區(qū)把過多精力耗費在了一些看起來很有前途，但實際上卻比較雞肋的服務項目中，比如容器服務Magnum、大數(shù)據(jù)服務 Sahara、數(shù)據(jù)庫服務 Trove、容器化部署服務Kolla。好吧，我曉得你可能有不同的看法，我不想爭論，還是來看用戶調(diào)查報告中的數(shù)據(jù)吧。

•  一方面，用戶對這些項目很感興趣。我認為至少有三個原因，一來是人們對新事物都有好奇心，二來是OpenStack社區(qū)的大力宣揚，三是殷切期望。下面的數(shù)據(jù)來自201704 用戶調(diào)查報告：

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

（備注：圖中的數(shù)字是百分比）

• 那到底是什么原因?qū)е逻@些新服務叫好不叫座呢？我認為有幾個原因：

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

下圖是一個我認為比較典型的私有云環(huán)境：

它具有幾個特點：

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

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

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

私有云環(huán)境中和公有云環(huán)境中，這些服務（其實應該稱為應用服務，與基礎服務分開來）的創(chuàng)建和管理方式迥然不同。在公有云環(huán)境中，因為多租戶需求，云供應商需要提供這些服務的創(chuàng)建和管理服務，使得用戶自行創(chuàng)建、管理和銷毀這些環(huán)境。但是，私有云中，并沒有那么多需求，需要反復地創(chuàng)建和銷毀這些服務的運行環(huán)境。因此，在OpenStack 中實現(xiàn)容器平臺、大數(shù)據(jù)平臺的自動化創(chuàng)建和銷毀服務這種需求不那么強烈，甚至可以認為是偽需求。針對這些新應用，OpenStack的使命首先應該是讓它們在自身平臺上『運行好』，而不是『把運行環(huán)境創(chuàng)建好』。

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

那為什么不應該在這些項目上浪費那么多時間，或者社區(qū)不該帶錯方向呢？

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

• 這些應用的原生部署工具更好。OpenStack上的對應項目，從一開始就做不好這些應用的環(huán)境的創(chuàng)建和管理，隨著這些應用的新版本發(fā)布，差距只會越來越大，到最后只留下一些既沒人維護也沒有用戶的半拉子項目。

• OpenStack 社區(qū)中這些項目基本上都是不能進入生產(chǎn)環(huán)境的半拉子工程，而且改動成本相當高。以我們使用Trove為例，在修改了幾乎一半的代碼后，也就實現(xiàn)了基本的數(shù)據(jù)庫實例創(chuàng)建和管理功能，離實際生產(chǎn)需求還有不小的差距。

• OpenStack 對 AWS 的學習只停留在『形』的表面，而沒有學到『神』。盡管AWS 上有一百多個服務，但是，我們看到的是AWS 扎扎實實地把基礎服務做好。舉幾個例子吧。區(qū)塊鏈現(xiàn)在很火是吧，AWS 上目前卻只提供了 CloudFormation 模板讓用戶自己去編排運行區(qū)塊鏈的云資源；Kubernetes 現(xiàn)在也很火是吧，但AWS 卻連管理K8S集群的界面都不提供。

  
  

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

• 以不變應萬變，做好這些新應用的運行基礎架構環(huán)境，使得這些服務可以良好地運行在由OpenStack管理的虛擬機/物理機、網(wǎng)絡和存儲中。

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

為什么OpenStack在青年時期就出現(xiàn)了中年危機呢？ 

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

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

• 以 AWS 為例，它有兩個容器相關項目，一個是它自研的ECS，這是一個Docker 容器管理服務，容器運行在EC2主機上。另一個是EKS，是一個Kubernetes 運行環(huán)境的創(chuàng)建和管理服務。AWS 為了支撐容器，主要做了幾件事情：1. 創(chuàng)造了 amazon-ecs-cni-plugin 項目，使得容器可以很好地運行在VPC 中。2. 打通了用戶權限，用戶可以使用 AWS 的賬號登錄到 Kubernetes 環(huán)境中。3. 實現(xiàn)了一套Docker 容器管理服務，以及K8S管理節(jié)點。

• 反觀 OpenStack 對容器的支持，它主要做了幾件事情，一是大張旗鼓搞 Magnum 項目，花很大力氣做K8S 環(huán)境的編排。另一個是有幾個網(wǎng)絡相關的項目，但是好像也沒什么人在用。

• 結果就是，在OpenStack 環(huán)境中，K8S 環(huán)境的編排也沒做好（當然了，要不要在私有云中做K8S 集群的創(chuàng)建和管理，前面有過討論），K8S 在OpenStack 環(huán)境中也運行不好（因為針對K8S的網(wǎng)絡、存儲都沒怎么搞好）。所以，我認為，是OpenStack 沒有及時為 K8S 做好支撐，才導致 K8S 和 OpenStack 的分離之勢的。

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

（3）部分OpenStack創(chuàng)業(yè)公司太浮躁，沒能做好非常關鍵的產(chǎn)品研發(fā)和服務。在高峰時，一些創(chuàng)業(yè)公司們追求的是社區(qū)的貢獻量，而不管貢獻質(zhì)量，甚至是刷貢獻量；追求的是用戶數(shù)量，不惜以低于成本價的方式，而不管項目能不能做成，用戶會不會滿意；追求的是PR文章和各種炒作，而沒能認真地去做用戶案例?？傊?，產(chǎn)品和服務沒有做好，用戶對OpenStack的口碑和信心沒有樹立起來。相對地，一些認認真真做產(chǎn)品的公司，其OpenStack云業(yè)務卻發(fā)展得很好，這說明OpenStack其實是可以做好的，用戶也是愿意用的。

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

OpenStack的未來到底會如何呢？

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

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

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

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

我對OpenStack的感情 

我對OpenStack有著挺深的感情。是它，讓我認識了什么是云，云是怎么構建的、是如何運行的、是如何維護的等等。是從研究它開始，我開始從傳統(tǒng)軟件領域進入了云領域，我也開始了寫博客的漫漫歷程，也通過它結識了很多朋友。因此，當看到有人故意詆毀它，甚至對它落井下石時，心里很不是滋味。其實，我覺得不光是我，整個IT領域都應該感謝OpenStack，它的出現(xiàn)大大加速了IT架構演進進程。

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

不管它的結局如何，OpenStack都將在IT發(fā)展史上留下了濃墨重彩的一筆。 在此，我想感謝OpenStack項目、感謝OpenStack每一行代碼和每一個文檔、OpenStack社區(qū)，和所有給OpenStack做過貢獻的公司和人們。