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

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

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

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

我做出的第一項預(yù)測就是，作為OpenStack(也包括任何其它云技術(shù))核心服務(wù)之一的計算服務(wù)將在新一年中發(fā)生巨大變化，即由原本的虛擬機管理程序為核心轉(zhuǎn)變?yōu)槿萜骷勇銠C組合模式。

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

除此之外，2015年當(dāng)中我們也經(jīng)歷了NFV(即網(wǎng)絡(luò)功能虛擬化)在OpenStack社區(qū)之內(nèi)的快速崛起，這也是電信與企業(yè)IT之間實現(xiàn)大融合的標(biāo)志性事件之一。

這份最新調(diào)查報告顯示，容器與NFV如今已經(jīng)成為OpenStack社區(qū)當(dāng)中最受關(guān)注的兩大創(chuàng)新成果，其重要程度甚至超過了PaaS。

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

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

而且正如之前所提到，我將引用OpenStack用戶調(diào)查以及其它一些報告內(nèi)容，并以此為基礎(chǔ)配合個人分析做出預(yù)測。

2016年OpenStack/私有云發(fā)展預(yù)測

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

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

[[161043]]

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

這又響應(yīng)了其它預(yù)測結(jié)論，例如Rob Whiteley曾經(jīng)提出的觀點：人才，而非技術(shù)，才是OpenStack實現(xiàn)成功的頭號關(guān)鍵因素。

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

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

預(yù)測一：指定OpenStack設(shè)備與托管部署項目將開始取代傳統(tǒng)發(fā)行版模式

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

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

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

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

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

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

預(yù)測三：PaaS已死，新PaaS長存

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

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

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

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

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

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

我預(yù)計在2016年當(dāng)中，電信行業(yè)將成為OpenStack部署領(lǐng)域的絕對龍頭，其接納程序遠(yuǎn)超企業(yè)客戶。

預(yù)測五：第二代OpenStack?以原生方式將Docker與OpenStack相結(jié)合需要對OpenStack核心做出本質(zhì)化調(diào)整。

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

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

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

預(yù)測六：混合云開始登上核心舞臺

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

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

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

而目前的變數(shù)則包括以下三項：

• 工具——新型編排框架與網(wǎng)絡(luò)虛擬化機制如今使得跨越多個云環(huán)境的自動化應(yīng)用程序部署流程成為可能。
• 由于消除了對專用鏡像格式的依賴性，容器的可移植打包單元使得我們能夠?qū)⑼卉浖郧八从械妮p松方式運行在多種云環(huán)境當(dāng)中。
• 大部分云服務(wù)提供共同的內(nèi)置容器支持基礎(chǔ)，這使得我們能夠更輕松地將工作負(fù)載在不同云環(huán)境間往來遷移。

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

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

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

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

在這個瞬息萬變的世界當(dāng)中，對未來做出準(zhǔn)確預(yù)測實在不是件容易的事。

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

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

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