雖然此前已經多次提及，但在這里我要再次強調2015年作為云計算全面崛起元年的重要地位，這在很大程度上是因為這一年內出現了眾多值得高度關注的大事件 ——包括戴爾/EMC的合并，而這些標志性事件意味著新的時代已然來臨。這是一種直白而決絕的表態，意味著全部傳統IT廠商都需要努力爭取自己的生存空間，否則必將為歷史所淘汰。

這場演進或者說革命則讓OpenStack處于非常有趣的定位之上，目前已經有大量“企業級”廠商——從思科到惠普再到IBM——開始將相當比例的 資源投入到OpenStack項目的推動工作當中。而Mirantis等新興廠商亦憑借著英特爾向其投入的另外1億美元確立了自己在新生代企業當中的領導 地位。而紅帽公司在這場競逐當中仍然表現良好，并繼續依靠自身強大的Linux發行版牢牢鎖定著現有客戶群體。

我們還親眼見證了Platform 9以及Stratoscale等新興廠商的快速崛起，它們不僅給傳統主流企業造成巨大沖擊，同時也威脅到了Mirantis及紅帽等新生代領導者。因此，考慮到以上狀況，2015年絕對是個值得認真回顧的精彩年份。

不過2015年的一切已然“俱往矣”，著眼于2016年做出展望顯然更具有現實意義。

我做出的第一項預測就是，作為OpenStack(也包括任何其它云技術)核心服務之一的計算服務將在新一年中發生巨大變化，即由原本的虛擬機管理程序為核心轉變為容器加裸機組合模式。

事實上，根據最新發布的OpenStack用戶調查顯示，有31%的受訪者將裸機、LXC以及容器以混合方式加以使用。這種方式也成為本屆 OpenStack東京峰會上的熱門新聞，而且OpenStack能夠支持一切計算資源的能力也正是其在云技術領域擁有差異化優勢的關鍵所在。值得強調的是，這也與Hedvig公司市場營銷副總裁Rob Whiteley的觀點不謀而合——他曾在2016年預測中表示Docker將成為OpenStack內的第二大重要虛擬機管理方案。

除此之外，2015年當中我們也經歷了NFV(即網絡功能虛擬化)在OpenStack社區之內的快速崛起，這也是電信與企業IT之間實現大融合的標志性事件之一。

這份最新調查報告顯示，容器與NFV如今已經成為OpenStack社區當中最受關注的兩大創新成果，其重要程度甚至超過了PaaS。

2014年是Docker強勢崛起的一年，而以其為代表的容器技術也徹底打亂了整個技術行業的陣腳。Docker的發展速度太快、規模太過 龐大，以至于無法為單一持有者所掌控。因此谷歌與CoreOS于2015年4月聯名要求Docker方面放松其底層核心引擎控制權，同時將剩余堆棧部分向 插件開放以避免其內部生態系統中的競爭問題。2015年6月，Docker宣布其正式在Linux基金會指導下建立產業聯盟。

現在回想起來，我認為自己當初做出的2015年預測確實比較靠譜，而這也讓我有了撰寫這份2016年OpenStack發展預測的動力。正如 Adrian Cockcroft所言，“IT支出沒能跟上開發人員的發展腳步。如果大家相對于采納新型技術成果而更關注成本支出，則意味著您的思路已經跟不上時代了”。

而且正如之前所提到，我將引用OpenStack用戶調查以及其它一些報告內容，并以此為基礎配合個人分析做出預測。

2016年OpenStack/私有云發展預測

房間里的大象(即少被談及但卻真實存在的事物)

我還記得當初 OpenStack項目剛剛誕生的日子，那時候我們曾經傾向于將其與Linux系統相比較。事實上，二者之間確實存在著諸多共通之處——它們都屬于大型開 源項目，而且直接立足于數據中心架構核心位置。然而經過了六年的發展與演進，我意識到這種比喻其實存在著很大的問題。云體系在復雜程度方面要遠遠高于操作 系統，而且其面臨的最大挑戰也并不單純在于技術層面或者成本支出。要想在云業務領域取得成功，大家需要具備能夠與Amazon、谷歌以及其它云服務供應商 相近的技能儲備、組織結構以及企業文化。很明顯，絕大多數企業——甚至包括那些擁有大型內部數據中心的企業——并不具備這樣的技能儲備與內部文化。而且更 重要的是，云業務的投資回報率目前仍不明確。

[[161043]]

這意味著如果在構建OpenStack發行版時完全假定遵循等同于Linux發行版的開發模式，那么其從核心層面就將存在著嚴重問題。因為 Linux發行版的構建思路會假設企業自身擁有IT部門，且相關技術人員有能力通過獲取發行版并利用典型IT方式——即由紅帽、Ubuntu、 Mirantis等廠商提供技術支持——實現云環境運營。但實際情況是，絕大多數IT部門根本沒有充分的技術力量來搞定這一系列難題，而將其轉化為云業務的舉措似乎也無法帶來明確的投資回報。

這又響應了其它預測結論，例如Rob Whiteley曾經提出的觀點：人才，而非技術，才是OpenStack實現成功的頭號關鍵因素。

另外一種有趣的現象在于，這種人才層面的空缺導致采用OpenStack技術的小型企業越來越少，而真正對其加以運用的大型企業則持續增長，正如以下示意圖所顯示：

考慮到當前構建私有云(包括OpenStack在內)所面臨的諸多難題，對于小型企業來講，最具實際意義及經濟效益的作法應該是采用公有云或者簡單的 Docker架構基礎設施，而非將資源投入到OpenStack當中。更重要的是，即使某些大型企業也僅僅在把小規模OpenStack部署體系視為專用解決方案。通過下圖可以看到，大型企業也仍然很難確切把握OpenStack的投資回報水平。

預測一：指定OpenStack設備與托管部署項目將開始取代傳統發行版模式

就目前/短期來看，企業將需要依賴于其它能夠提供完整 OpenStack運營環境的供應商來建立自己的云體系。這意味著我們將看到企業客戶擺脫現有發行版模式——即選擇預打包設備并配合與之相適應的特定底層 硬件——束縛，轉向更為靈活的實現方向。事實上，Mirantis、惠普以及思科都在引領著這一風潮，而Stratoscale等初創企業也開始加入進 來。

在我看來，我們還將看到更多企業選擇OpenStack的托管版本，在這種情況下他們將把整體私有云運營體系外包給擅長這一領域的第三方專業廠商。Rackspace公司以及CSC、埃森哲等傳統系統集成商將在這方面占據優勢地位。

總結起來，以上解決方案都能在一定程度上解決企業在運營OpenStack云時技能儲備不足的問題，但這還并不足以幫助我們將OpenStack 作為首選運行環境——而這正是我們實現業務敏捷性并降低成本的必要前提。為了能夠讓OpenStack繼續在市場上獲得關注與采納，相關社區必須邁向軟件發行版這一固有局限，并同其它低成本云方案實現對接?？紤]到這一點，我提出了下一項預測……

預測二——新型OpenStack平臺崛起，利用OpenStack作為其它私有/公有云中的通用型抽象層

VMware公司已經發布將利用VIO支持OpenStack。關于VIO，有趣的一點是其利用OpenStack作為立足于傳統VMware堆棧之上的抽象層，這意味著 VMware用戶可以在投入OpenStack懷抱的同時繼續享受VMware基礎設施的出色成熟性水平。這還允許此類用戶繼續運用自己的現有 VMware技能儲備，并大大簡化由VMware向OpenStack這一過渡過程。

Platform 9是一家初創企業，承諾立足于Amazon或者其它云資源交付一項OpenStack服務。著眼于Platform 9方案，其最大的亮點在于能夠顯著降低運行OpenStack的入門門檻，而且得以利用AWS、Google Cloud Compute、VMware乃至其它云服務供應商底層云資源的成熟度與成本效益，從而將OpenStack作為一種通用型抽象層運行在全部現有云平臺之上。

預測三：PaaS已死，新PaaS長存

Docker提供一套獨特的部署模式，這直接導致傳統的特定PaaS方案變得毫無吸引力。而最近的OpenStack用戶調查也顯示，作為專門圍繞Docker打造的補充性方案Kubernetes以及微服務架構已經獲得快速發展勢頭，此外 Docker Swarm、Mesos以及Cloudify也運作良好。而更有趣的是，這份清單當中的全部成員都采用了不同于PaaS內“Heroku”型應用管理與自動化機制的新型解決途徑。Cloud Foundry目前仍然處于領先集團，而OpenShift則以較小差距位居第三，不過Cloud Foundry與OpenShift還需要對自己的整體產品進行梳理，從而適應面向容器的遷移趨勢。而最值得指出的一點在于，OpenShift已經開始針對Kubernetes進行重構。

另一項有趣的事實是，這份清單中沒有任何一個上榜項目屬于OpenStack發行版的組成部分。一種可能的解釋在于，用戶可能更傾向于把自己的應用平臺從其基礎設施當中解耦出來。

著眼于2016年，我預計全部應用程序平臺都將面向容器及Kubernetes提供支持。Mesos與Kubernetes已經在很大程度上成為彼此互補的方案組合。我認為這兩套平臺將繼續發展并構成完善的堆棧體系，而二者之間的交集部分則更多以備選競爭方案而非互補方案的形式存在。目前尚不確定的 是，戴爾收購EMC的舉措是否會給Pivotal帶來影響，而Docker/Kubernetes的崛起也將成為Pivotal/Cloud Foundry快速發展的催化劑。我認為OpenShift在這種背景下將擁有更為有利的市場定位，因為其已經在很大程度上開始向Kubernetes傾 斜。不過需要指出的是，OpenShift選擇Kubernetes作為基礎的作法可能導致引入另一額外抽象層的風險，因此其最終結果或者說價值回報目前 尚無法確定。

盡管我們可以看到容器技術已經迎來了明確的擴展態勢，但我認為真正實現全面容器化恐怕還需要經過多年的推進，而微服務架構的普及甚至需要花費更長時 間?？紤]到這一點，我認為2016年年內市場還不太可能將大部分負載部署并運行在微服務/Kubernetes這類混合型工作負載環境當中。在這方面， 較理想的實現方式是利用Kubernetes作為面向微服務架構的部署目標，并利用其它編排方案運行數據庫、大數據、事件處理以及各類更為復雜的工作負 載。與此同時，Cloudify與OpenStack/Magnum已經被定位為集成平臺，其允許用戶向其中粘合多種不同類型的工具與工作負載。

預測四：別無選擇之下，電信行業將成OpenStack采納之先鋒。

盡管OpenStack的投資回報率在企業領域受到公有云服務的有力沖擊，但OpenStack在電信運營商層面卻成為惟一的解決方案——換言之， 電信運營商惟有借此方能與迅速崛起的公有云服務供應商相抗衡。考慮到這一點，我們可以從下圖當中看到，網絡功能虛擬化(簡稱NFV)機制開始在 OpenStack用戶當中快速普及開來：

我預計在2016年當中，電信行業將成為OpenStack部署領域的絕對龍頭，其接納程序遠超企業客戶。

預測五：第二代OpenStack?以原生方式將Docker與OpenStack相結合需要對OpenStack核心做出本質化調整。

將Docker集成至OpenStack當中的方案就目前而言主要分為兩種，其一為將Docker視為額外的計算節點，其二則是利用Magnum對Kubernetes及Mesos等堆棧層提供支持。

盡管這看起來算是不錯的起點，但卻未能發揮容器技術的相當一部分核心價值，即提供一套完整的計算、網絡與存儲堆棧。

為了全面迎接容器時代的來臨，OpenStack將需要超越現有核心架構，轉而著眼于潛在的、專門為容器提供原生支持的新型OpenStack核心。紅帽公司似乎在這方面走在了時代前列，而且其已經于本屆東京OpenStack峰會上發布了一套容器原生堆棧。(值得注意的是，此次發布的方案與現有 OpenStack服務幾乎無甚關聯。)我認為在2016年當中，我們將迎來Docker以原生方式集成至OpenStack核心當中的一波浪潮。我認為由此帶來的結果就是，下一代OpenStack將直接提供原生容器解決方案并因此在易用性與輕量性方面超越其現有版本。

預測六：混合云開始登上核心舞臺

自誕生之日開始，OpenStack項目就一直被視為AWS及其它云服務的替補性方案。

不過在真實世界當中，OpenStack一直被用于同其它云環境相對接——目前最流行的使用方式就是利用VMware作為其私有端，而由AWS充當公有云端。

話雖如此，大部分用戶實際已經建立起了自己的一套松散私有云環境，其中分別使用OpenStack、VMware或者Amazon元素，而且不同環境之間幾乎沒有任何交集。之所以采用這類方案，部分原因在于真正建立起一套嚴格的混合云部署體系確實非常困難。

而目前的變數則包括以下三項：

• 工具——新型編排框架與網絡虛擬化機制如今使得跨越多個云環境的自動化應用程序部署流程成為可能。
• 由于消除了對專用鏡像格式的依賴性，容器的可移植打包單元使得我們能夠將同一軟件包以前所未有的輕松方式運行在多種云環境當中。
• 大部分云服務提供共同的內置容器支持基礎，這使得我們能夠更輕松地將工作負載在不同云環境間往來遷移。

使用混合云戰略的另一大重要動機在于投資回報率。正如我之前所提到，構建OpenStak項目的成本往往相當驚人。而削減OpenStack基礎設 施規模的一大重要舉措在于將OpenStack同其它公有云相結合，這意味著私有云實例拓展至按需實例，并借此提升業務敏捷性且降低總體使用成本。

考慮到上述因素，我們相信2016年各OpenStack項目將把建立更為緊密的混合云方案作為首要目標甚至是先決條件。

容器與Kubernetes的介入，再加上OpenStack提供的TOSCA支持能力，將共同通過TOSCA解析器項目體現出效果，與此同時Cloudify亦將在此類方案當中獲得一席之地。

最后說明：變化是惟一不變的要素

在這個瞬息萬變的世界當中，對未來做出準確預測實在不是件容易的事。

而OpenStack最令我贊賞的一點在于，其顯然高度關注并尊重來自用戶的需求與反饋聲音。本次OpenStack用戶調查報告的投資規模一項也證實了上述結論。截至目前，這份最新用戶調查已經是最為全面且明確的統計觀點。在這里要感謝相關人員的付出與努力!

無論如何，變化是惟一不變的要素——因此如果要總結出一條放之四海而皆準的建議，那么我希望大家能夠“積極擁抱變化”。在規劃自己的2016年 OpenStack發展戰略時，請大家保證自己的選擇足以快速接入新型技術成果，而這種創新工作的實現速度將高度取決于這種接入速度。

原文鏈接：http://dockone.io/article/935?utm_source=tuicool&utm_medium=referral