摘要：彼時，從虛擬化管理到公有云，熱鬧異常。雖然年才明顯放棄公有云的全面競爭，但在年決定發起和開源項目是，不說明確，至少已經隱隱覺得肯定搞不過亞馬遜了。年前賣的多火，被視為虛擬主機的升級版。當然不是新堆棧，而是傳統堆棧。

還記得在十多年前，SaaS鼻祖SalesForce喊出的口號『No Software』嗎？SalesForce在這個口號聲中開創了SaaS行業，并成為當今市值460億美元的SaaS之王。今天談談『No Server』有關的事。繼OpenStack、Docker 、MiscroService、Unikernel、Kubernetes和Mesos之后，ServerLess正成為Google亞馬遜乃至創業公司暗戰的新戰場，它們能否成為云計算領域的顛覆性趨勢？

?

1、開始于Eucalyptus終結于OpenStack，不僅是從眾而且想取巧并彎道超車

在2008、2009、2010那三年，雖然過來還處于云計算的蠻荒年代，但國外敏銳的開發者和公司已經看到的云計算的星星之火。像國人一樣，他們 也想在這火成燎原之勢前，以最小的風險、最小的投入、最快的時間，分得較大一杯羹。

當然，最先行、最敏銳的是開發者們。

彼時，從虛擬化管理到公有云API，熱鬧異常。

虛擬化管理曾領過風騷的就有Virtualiron、3tera、qlayer、OpenNebula、Abiquo、virt-manager、oVirt、XenServer、ConVirt、Ganeti、Proxmox、Enomalism。相信我，2009年4月的時候，最牛的就是這幾個：Enomalism、ConVirt、oVirt、Virtual Manager。那會連Eucalyptus都感覺很難用。

當然，最后歸結于Eucalyptus 、CloudStack和OpenStack。

關于他們的優劣和成敗原因的分析，已有很多。三者中，Eucalyptus出身最學術，CloudStack出身商業味最濃，OpenStack介于兩者之間。或許，這是OpenStack成功的重要因素？我認為采用Python語言也是重要因素之一。

Eucalyptus出現最早，2008年就出來了，是由加州大學圣塔芭芭拉分校的Rich Wolski和他的博士弟子們開始的。NASA最開始也是使用的Eucalyptus啊。但是，學術機構，還是從事HPC的嘛，雖然一開始就對標和兼容EC2 API，但可用性還是差了那么些，特別是對商業運作敏感性查了一些。及至后來引進了MySQL的創始人Martin，加快了商業化步伐，怎奈OpenStack勢頭已成，且OpenStack沒有商業公司控制，這一點很重要，大咖們都喜歡玩不受商業公司控制的，由基金會管理的項目。

OpenStack出現的晚多了，2010年才出現。NASA最開始也是使用Eucalyptus，據說NASA想給Eucalyptus開源版本貢獻patch，但Eucalyptus沒接受，Eucalyptus不會玩社區嘛。NASA 的六個開發人員，用了一個星期時間用Python 做出來一套原型，結果，能跑。這就是Nova的起源。NASACIO 跟 Raskspace一個副總走得近，于是NASA 貢獻 Nova，Raskspace貢獻Swift ，在2010年的7月發起了 OpenStack 項目。

CloudStack也在2008年成立。CloudStack一開始就用了cloud.com這個域名，讓我覺得背后的團隊太有商業眼光了。這個域名肯定花了不少錢，但將來一定能掙回來。因為那會用全部力量撲在虛擬化上的團隊，不多。那會，OpenStack剛成立的時候，CloudStack還是OpenStack的成員呢。為嘛？我也沒想通。

但是，CloudStack和Eucalyptus一樣，最開始并不開源，開源后還留了點尾巴，而且自己控制著商業版本。等發現這種模式玩不轉了，2011年7月賣給了Citrix，全部開源后，發現大家已經都在玩OpenStack了。

OpenStack太好了？為什么？有人已經貢獻了很多代碼了，其實OpenStack發布后直到CloudStack被Citrix再轉賣出去為止，OpenStack的易用性和穩定性一直和CloudStack有差距。但是架不住OpenStack免費、完全開源、沒有商業公司控制。

這多好，天上掉下的餡餅。拿來就能用，改改界面就是自己的版本啦。就有軟件和產品了，有解決方案了，甚至可以做公有云和亞馬遜AWS一決雌雄了。

嘿，這事RackSpace最有發言權。雖然Rackspace 2015年才明顯放棄公有云的全面競爭，但在2010年RackSpace決定發起和開源OpenStack項目是，不說明確，至少已經隱隱覺得肯定搞不過亞馬遜AWS了。那時，他們與亞馬遜AWS的競爭已有三年。

OpenStack本來想另起爐灶，搞一套和AWS EC2不同的API，利用代碼和API的開放性，糾結開發者和業內公司，形成一個生態系統，對抗AWS。但是后來，從API到架構，越來越像AWS。

RackSpace當然是這么想的，但是后來的發展卻不受自己控制了。來的小公司當然很多，大腕也是不少。當然，RackSpace的投入也是不少。股票得靠云計算支撐啊。公有云發展慢了，OpenStack也是個招牌。RackSpace的云主機不是收購的slicehost嘛，后來有沒有用OpenStack不知道，但云存儲基本用的是Swift，基于哪個版本就不好說了。

我猜的是，OpenStack對RackSpace的公有云沒有明顯幫助。因為OpenStack這樣的軟件能在一個公有云的運營里面占據的角色太基礎了，而且OpenStack需要考慮眾多廠家和參與者的需求。

接著上面說，天上掉下的餡餅，誰遇到這好事不嫌棄。其實OpenStack就功能和穩定性來說，那幾個大廠家復制一個是沒有問題的。但是，聲勢不夠，沒有名聲。IT圈也是個圈啊，沒有名頭也沒人關注啊。純商業版的，VMware和微軟已經夠了，再搞一個沒人要的，還不如在當紅炸子雞OpenStack上投入和榨點油水。當然，也有不少，把大把銀子和大堆的人力投入在OpenStack上的。

不投不行啊，自己搞一個沒人關注。還不如找個有名頭的繼續包裝。大公司無奈如此。小公司反而更好辦了，反正一無所有，拿個現成的起步，有是在東西，還有響亮的名頭，必須上啊。

國外不知道，中國想以OpenStack為生的公司么有100家，也有50家。

當然，后來的結果大家都知道了。OpenStack搞AWS沒戲，投入較大的HP Helion都要關閉了，其他拿OpenStack搞公有云的就更不用說了。

從RackSpace開始，大家拿OpenStack開始搞私有云。私有云？從開頭說的那些開源的，到VMware VShpere、微軟ystem center，那都是相當成熟的。恩，就是貴了點。

現在OpenStack開始往下走了，私有云了嘛。以前是管理和集成，現在深入到更底層的了，從虛擬機的大頁內存、CPU綁定、IO調度，到網絡的SDN、NFV，這都得有啊。私有云軟件，這個都是可以控制的。OpenStack現在回過神來搞私有云，那這些都得搞。

但是，有多少人和公司想過，自己需要的是一個新玩意還是一個虛擬化管理工具？是OpenStack的復雜性可擴展性還是順手和可靠？當然沒有多少人在用之前，對虛擬化管理軟件領域有充分的了解，也不一定有資源做充分的調研，流行的就是好的。

后面的事，大家都知道了。CloudStack2015年底被Citrix轉賣給Accelerite，而Eucalyptus早在2014年9月就已經委身于HP。

競爭對手一個個倒下，看似勢頭無敵的時候，也就是最危險的時候。這不，還沒等干掉對手的時候，Docker就來了。Docker的淵源雖然很古老，但本身誕生于2013年，是OpenStack紅得發紫，各公司蜂擁而上的那年。

誰也想不到，Docker這個老古董能掀起這么大的波瀾，差點讓OpenStack翻船。OpenStack最牛的是勢，而Docker也是來勢洶洶。看看下面的圖，IT圈曝光率也是基礎啊，面對Docker，OpenStack不心慌才怪。

但其實Docker是半個老古董。

2、Docker這半個老古董，掀起了第二波從眾而且想取巧并彎道超車的浪潮

沒錯，第二波終于來了。

因為不但搞OpenStack的沒能搞定公有云，不搞OpenStack的也沒能搞掂公有云。得有點新東西出來。

我們先從看看Docker有多老開始。現在看到的Docker的起源都不能算起源，只能說出生。其實Docker也有老祖先七大姑八大姨的。

任何東西都能追溯到老祖先，虛擬化還能追溯到70年代的大型機呢。那個是有點牽強了，但是Docker的直系親屬那也是夠老的。

遠房的親戚就不說了，新生代的KVM都6、7年的歷史了，老一代的Xen和QEMU從2003年算起都十二三年的歷史了。在IT行業，10年已經很久了。

但Docker的近親，歷史也不短，甚至有的更久。Docker它爸LXC從2006年開始開發，到2008年發布0.1.0版本，Docker直接間接使用的其他組件Chroot、cgroup、namespaces、libcontainer的歷史當然也不會比LXC短。它叔叔Linux-VServer在2003年就已經發布了1.0版本，這是基于內核態隔離的容器。它還有眾多表兄弟Cloudfoundry Warden、BSD Jails、AIX workload partitions、iCore Virtual Accounts、Sandboxie、Virtuozzo等等，其中Virtuozzo、OpenVZ和Solaris Container歷史都在十年以上。

關注虛擬化和IDC的，有些Docker的親戚應該是很熟悉的。這回又提到IDC了，云計算真實上輩子就跟IDC糾纏在一起。收費的Virtuozzo、免費的OpenVZ，那是云計算和云主機出現之前，Xen和KVM出現之前，搞VPS的利器。10年前VPS賣的多火，被視為虛擬主機的升級版。

OpenVZ是Virtuozzo容器技術的linux版，LXC是OpenVZ為了融入內核開發的對應版，開發者大部分是同一批人。LXC及周邊工具就是現在Docker的重要組成部分。

Docker出現也就5，6年，但它的大部分身體都出現差不多10年了，你說它是不是半個老古董呢？

Docker本身大家都很熟很熟了，不用贅言。不過經常有人拿Docker和Xen、KVM支持的虛擬機對比，說占用體積小、啟動速度快，不是一個層級的東西好嘛，一個在操作系統之上，一個在操作系統之下，不贅言了。Docker當然也不能和LXC等Linux容器對比，都是用的同一系列核心工具，只是管理層不同而已。

Docker在2013年底，2014年初，突然吸引了眾人的目光，并在2014年2015年集萬千寵愛于一身，就如前兩年的OpenStack一樣。

回到Docker誕生的年代，2010年，幾個年輕人在舊金山成立了一家做 PaaS 平臺的公司dotCloud。大家現在都知道Heroku，也是PaaS型，而且，也用到了容器，可能是LXC吧。當然不是新堆棧PaaS，而是傳統堆棧PaaS。這和Heroku一樣，為開發人員提供操作系統、通用庫、特定語言的運行環境，應用的部署、管理、監控等。

dotCloud把需要花費大量時間的重復性工作，抽象成組件和服務，如規范容器的格式、便利容器的生命周期管理等，方便開發者管理和監控自己的應用。

正如我在《云計算時代》一書中所言，新堆棧PaaS離開發者現有技能太遠，傳統堆棧PaaS離現有堆棧太近。不管哪種，都擋住了開發者掌控一切的意愿。所以，PaaS多年來雖然獨立作為一類云服務，并沒有足夠大的市場。

雖然dotCloud 在2011年初拿到了1000萬美元的融資，但這個市場本沒有那么大，也沒有快速的增長，容納不下太多的企業。也沒有干過Heroku、Engine Yard等公司，自然前景不妙。

dotCloud 的創始人 Solomon Hykes 把大伙召集到一起，大家琢磨了一下，商業是沒戲了，那也要搞一把非商業的事情，把我們在容器上的工作起名Docker開源出來。能不能把競爭對手干掉不好說，希望是挺渺茫，但是起碼能在社區留個名！萬一，開放開源能夠搞成更大的勢頭，公司還能起來呢。

是不是和RackSpace當初搞OpenStack有幾分相像？狗急了還要跳墻呢，絕處逢生不是不可能。所謂堅持，耐心，就是這個意思。只是這是一條高風險高收益的路罷了。

LXC，包括OpenVZ，在2013年之前，可不只是Heroku等PaaS公司在用，有些公司內部都在使用，甚至包括我在內的一些公有云從業者也慎重考慮過用容器作為公有云的基礎。當然，還真有這么干的。Joyent大概是除了AWS之外，干公有云最早的了吧，可能比RackSpace還早點，就是基于Solaris Zone賣云主機的。Joyent的技術骨干是從SUN出來的，精通Solaris，他們整了一個基于Solaris的精簡內核，專門用來跑Zone，類似于CoreOS，叫做SmartOS，基于這個做出了私有云軟件SmartDataCenter。說這些可能沒幾個人知道，但是鼎鼎大名的Node.js很多人熟悉，就是Joyent開發維護的。

沒錯，LXC和OpenVZ用在企業內部是很好的，非常好。但是限于LXC當時的管理工具欠缺，并沒能大規模流行起來。它需要一個契機。這個契機就是Docker，Docker解決了LXC的管理問題。

電視劇總是那么相似，相遇、離別、重逢，受苦受難、遇到高人、報仇雪恨，IT圈的故事也逃脫不了這樣的情節。Docker的故事，真的和OpenStack，包括此前的Linux等其他開源軟件，有幾分相似。

dotCloud把自己在容器上的工作成果Docker開放開源了，開發者和小公司雀躍了：又來一個餡餅啊。這個餡餅解決了一些問題，讓其他人和開發者免除了管理和開發工作量，這是次要的。更重要的是，后來參與的開發者、小公司、大公司對Docker的期待，遠不止解決容器本身的管理問題，也不只是因為有一批人喜歡而從眾，還有一個很多人很多公司沒有說出的理由：容器是未來，干掉現在的私有云和公有云。

Docker 如此受歡迎，2013年10月 dotCloud 公司更名為 Docker 公司。2014年8月 Docker把平臺即服務的業務dotCloud出售給位于德國柏林的平臺即服務提供商cloudControl，2016年初 dotCloud被cloudControl關閉。而Docker公司開始全身心運營Docker社區，并開展Docker商業化。

Docker 迅速成長為云計算相關領域更受歡迎的開源項目，Amazon、Google、IBM、Microsoft、Red Hat 和 VMware 都表示支持 Docker 技術或準備支持。據說，有 Linux 的地方，就可以運行 Docker。Mac上也可以，Windows 上都有直接運行 Docker 的 Windows Docker 和 Nano Server，當然，這已經是 Windows 版的了。

截止2016年初，Docker 獲得 5 輪 1.8 億美元融資，推出了Docker Hub、Docker Trusted Registry、Docker Tutum等產品，試圖控制Docker容器的存儲、管理。在2015年上半年與OpenStack的論戰之后，雙方握手言和，以OpenStack支持Docker管理告終。

Docker當然不甘心只是一個工具軟件，也是要做產品、平臺的，拿投資人的錢可不能做公益做開源啊。凡是有威脅的就要干掉，或者收掉。于是Docker收購Unikernels。

3、Docker為何收購Unikernels？既是看好更是感到威脅

容器作為虛擬化技術的一種，在云計算出現之前就出現了。之所以在2014年前后流行，是因為大家需要一種與硬件虛擬化更輕量級的技術，來有效運轉私有的基礎設施。這個私有的，既可以在自家機房里也可以在公有云上。

在私有的基礎設施上，至少某些應用場景，Docker因為其輕量級，應用啟動更為迅速，資源利用更為高效。但是，循著這個思路，Unikernels更進了一步。

我們先來看看怎么回事。

從操作系統誕生以來，它就扮演了一個應用和硬件之間的平臺的角色，提供對硬件的控制。除了操作系統內核和基本的控制臺，還有軟件開發接口、語言運行時環境、語言庫、輸入輸出設備控制，也需要支持各種古老的和新興的硬件標準。它需要支持多用戶、多進程、多設備并發。

雖然操作系統的的用途各異，有桌面的、內部IT系統的、有面向網絡的，但操作系統的架構和模塊基本相同，一致沒有大的改動。但在上世紀90年代后期，Hypervisor被引入了主流的操作系統。Hypervisor運行于硬件之上，能支持多個虛擬機運行多個不同的操作系統。但這一變化，并未對操作系統的設計產生大的影響。每一個虛擬機仍然運行著一個傳統的操作系統。

但是當Hypervisor推動了云時代的到來后，通用操作系統的局限就更明顯了。在云環境中，由于規模更大，負載被明顯分成了不同的類型：Web服務器負責處理網絡請求，數據庫服務器負責數據庫的運行和數據庫訪問，等等。這些服務器可能永遠都用不上顯示器、多用戶、多進程。這些場景下的VM和OS的任務很明確，就是提供較好的存儲、計算、網絡性能。

開發者們開始質疑操作系統的的設計和架構：為什么一個Web Server上要安裝它從來用不到的軟件？其實在此之前，Windows服務器就遇到過類似的問題。我們只需要能快速擴展和收縮VM的規模，VM越精簡越輕量級越有利于這種彈性。但由傳統操作系統構成的VM，只能勉強完成這個任務。

Docker所代表的容器恰逢其時。因為基礎技術早已就緒，流行很快。因為能在同一個操作系統上快速運行多個隔離的輕量級的，容器基本解決了上述疑問。容器封裝了應用程序所需要的一切，除了共用的操作系統內核，它封裝了運行時環境、框架和庫、代碼、配置和相關的依賴。容器大大削減了操作系統作為一個全能平臺所承擔的角色。容器之下的操作系統這時只需要承擔一個非常輕量級的角色：啟動和控制容器。這時的操作系統更為專業化，而容器承擔了運行各種不同場景所需資源的角色。

這種趨勢催生了容器的Hypervisor的產生：CoreOS,RancherOS,Redhat Atomic Hosts,Snappy Ubuntu Core,Microsoft Nano。他們是為了支持在其上運行容器而存在，沒有其他的任務，已經非常精簡。甚至Hypervisor之上的容器，有人又將其區分為操作系統容器和應用容器，應用容器就是只為單一應用為目標的容器。到這里，微服務（MicroService）終于可以見天日了，終于能夠使用了，而所謂的SOA、Mashable是不是能夠換發新的光彩呢？

但這種精簡、輕量級還沒有到此為止，Unikernals出現了。在2014年初就出現了，那時Docker剛剛開始崛起。

Unikernals將這種最小化操作系統的理念往前進一步推進。它是一個定制的操作系統，專為特定的應用程序的運行而編譯。因此，開發者能夠創建一個極度精簡的OS，只包含應用和它所需的操作系統組件。Unikernals是單用戶、單進程、單任務的定制操作系統，它在編譯時去除了所有不需要的功能，但包含了一個軟件運行所需的全部堆棧：OS內核、系統庫、語言運行時環境、應用，這些被編譯成一個可啟動的VM鏡像，直接運行在標準的Hypervisor上。

Unikernals讓操作系統之上的容器又變成了一個操作系統，不過這是一個重新吧便宜的極為緊湊的，直接運行在Hypervisor而不是精簡的通用操作系統上的操作系統。Unikernel有著更小的尺寸，更小的可攻擊面，啟動時間也以毫秒計。Unikernals的論文在這里：https://queue.acm.org/detail.cfm?id=2566628。

不過，和Docker一樣，靈活帶來的伴生問題，就是管理、監控、回溯、審計，有運維工程師說，Docker就是運維的噩夢，那Unikernals可能是運維和開發者的噩夢？為啥，因為對應用改一行代碼要重新編譯整個鏡像并部署，無法對一個Unikernals實例打補丁，也就是說Unikernals的實例是靜態的。

Unikernals的例子包括MirageOS、Clive、OSv，目前都跑在Xen Hypervisor上。它有多小呢？一個MirageOS DNS鏡像是200KB，而一個目前全球90%DNS使用的開源DNS服務器BIND鏡像是400MB。而MirageOS DNS鏡像的性能據稱比BIND好45%。

咦？這不是嵌入式系統嗎？Unikernals當然可以編譯出鏡像，運轉在低功耗的設備上。如果Unikernals被移植到ARM平臺上，開發者就可以編譯出運行在ARM設備的hypervisor上的鏡像。這將讓嵌入式應用的開發更為容易。

那么，看起來，Unikernals雖然現在更像一個極客玩具，但是，不可否認，Unikernals有代替容器和虛擬機的可能，至少在某些場景下。既然容器比虛擬機在某些場景下更好，為什么更精簡的Unikernals就不能代替容器和虛擬機呢？

有可能。而且這個理念和Docker代表的容器理念相符。于是，Docker收購了它。大家一起玩，一起干掉虛擬機。

Docker看起來無敵，前景光明。但是，道路還是曲折的。

大佬們是想干掉私有云和公有云的啊，你Docker公司守著這個熱門技術不放，控制的緊緊的， 我們怎么玩？不光是大佬，創業公司也不干啊。

首先發難的是CoreOS和谷歌。

4、CoreOS反水，Kubernetes和Mesos把docker打回工具原型

CoreOS首先不干了。

CoreOS原本是Docker初期的鐵桿盟友，CoreOS可以說就是為Docker而生的Linux，它的任務就是管理好Docker。但是隨著Docker開始商業化，Docker對鏡像格式和代碼收緊了控制，甚至建立開放平臺存儲Docker鏡像和認證，當然，還發布了Docker管理工具。

那CoreOS的位置在哪里？當然，理由還是要像樣一點的：Docker的鏡像格式不夠靈活，工具鏈太龐大，我們要靈活而精簡的東西。

于是CoreOS自己搞了一個容器：Rocket。本來嘛，大家都是基于LXC等工具的，這些工具都是開源開放，而且CoreOS也搞容器管理的，新搞個格式和管理工具還不是手到擒來。

當然，雙方都承認，Docker和Rocket不是直接競爭關系。Docker是一個產品，并正在成為一個平臺。Rocket只想做一個容器管理的組件。但是，雙方還是分道揚鑣了。

CoreOS一個人可沒這么大的氣勢，背后還有谷歌撐腰。Rocket很快被Kubernetes支持。

Kubernetes的靈感來源于Google的內部borg系統，吸收了包括Omega在內的容器管理器的經驗和教訓。2014年6月谷歌宣布Kubernetes 開源。谷歌想靠容器翻身呢？怎么能讓另一個商業云公司控制最流行的容器。

Kubernetes算是一個與Docker平臺競爭的容器管理工具，自然首先支持Docker，但是也支持競爭對手Rocket。

但是Kubernetes也有一個潛在對手：Mesos。Mesos比Kubernetes出現得早，而且兩者都深受谷歌的數據中心管理你項目Borg和Omega的影響。問題是，Mesos不是谷歌自家的，雖然屬于Apache項目，但仍被商業公司Mesosphere，也是Mesos重要維護者主導。Mesos被稱為數據中心操作系統，軟件定義數據中心的典范。

Mesos既是計算框架也是一個集群管理器，是Apache下的開源分布式資源管理框架，它被稱為是分布式系統的內核，可以運行Hadoop、MPI、Hypertable、Spark。使用ZooKeeper實現容錯復制，使用Linux Containers來隔離任務，支持多種資源計劃分配。Mesos使用了與Linux內核相似的規則來構造，僅僅是不同抽象層級的差別。Mesos從設備（物理機或虛擬機）抽取 CPU，內存，存儲和其他計算資源，讓容錯和彈性分布式系統更容易使用。Mesos內核運行在每個機器上，在整個數據中心和云環境內向應用程序（Hadoop、Spark、Kafka、Elastic Serarch等等）提供資源管理和資源負載的API接口。

Mesos也不是也不是沒有隱憂，Apache yarn似乎有一統分布式計算之勢，MapReduce，Spark，Storm，MPI，HBase都在向yarn上遷移。當然，好在Mesos不僅僅是做分布式計算的框架。

Mesos也起源于Google的數據中心資源管理系統Borg。Twitter從Google的Borg系統中得到啟發，然后就開發一個類似的資源管理系統來幫助他們擺脫可怕的“失敗之鯨”， 后來他們注意到加州大學伯克利分校AMPLab正在開發的名為Mesos的項目，這個項目的負責人是Ben Hindman，Ben是加州大學伯克利分校的博士研究生。后來Ben Hindman加入了Twitter，負責開發和部署Mesos。現在Mesos管理著Twitter超過30,0000臺服務器上的應用部署。

Borg的論文2015年四月才發布：http://research.google.com/pubs/pub43438.html

Mesos的論文：https://www.cs.berkeley.edu/~alig/papers/mesos.pdf

Omega的論文：http://research.google.com/pubs/pub41684.html。

這一回，谷歌論文發晚了，雖然也很有價值，但可能沒有三大論文那么有影響力。

2014年7月，Mircrosoft、RedHat、IBM、Docker、 CoreOS、Mesosphere 和Saltstack 加入Kubernetes。

2015年1月，Google和Mirantis及伙伴將Kubernetes引入OpenStack，開發者可以在OpenStack上部署運行Kubernetes 應用。

2015年7月，Google正式加入OpenStack基金會，Kubernetes的產品經理Craig McLuckie宣布Google將成為OpenStack基金會的發起人之一，Google將把它容器計算的專家技術帶入OpenStack,成一體提高公有云和私有云的互用性。

同時，谷歌聯合Linux基金會及其他合作伙伴共同成立了CNCF基金會(Cloud Native Computing Foundation)，并將Kubernetes作為較早的編入CNCF管理體系的開源項目。來，我們來看一下發起人：AT&T, Box, Cisco, Cloud Foundry Foundation, CoreOS, Cycle Computing, Docker, eBay, Goldman Sachs, Google, Huawei, IBM, Intel, Joyent, Kismatic, Mesosphere, Red Hat, Switch SUPERNAP, Twitter, Univa, VMware and Weaveworks。

到此是不是大團圓了？所有跟容器有點關系的都來了。谷歌加入了OpenStack基金會，OpenStack上可以部署運行Kubernetes，OpenStack支持Docker，Mesos支持Docker和Kubernetes。大家互相都支持，誰能發展好，各自努力吧。這關系夠亂的。

但是，容器的另外兩個大玩家-亞馬遜和微軟，沒有到場。沒錯，容器界就是要掀翻現有的云計算格局，當然不能讓云計算老大和老二進來了。

谷歌糾集了一幫小兄弟，誓要利用容器浪潮，干翻亞馬遜AWS和微軟Azure。當然，谷歌也沒有奔到準備靠一招制勝，暗戰還有另一個戰場：Serverless。

5、Serverless是云計算的決勝負戰場？

2014年11月14日，亞馬遜AWS發布了新產品Lambda。當時Lambda被描述為：一種計算服務，根據時間運行用戶的代碼，無需關心底層的計算資源。從某種意義上來說，Lambda姍姍來遲，它更像S3，更像云計算的PaaS理念：客戶只管業務，無需擔心存儲和計算資源。

比如你要架構一個視頻服務，你需要用一堆服務器，設計出一套上傳、解碼、轉碼的架構。但是，可能這套系統99%的時間都是空閑的。而使用一個Lambda function，你就不需要操心服務器和這套架構，當AWS探測到用戶定義的時間，比如用戶上傳了一個視頻文件，Lambda自動運行響應的程序，結束后關閉程序。為客戶生了時間和金錢。

Lambda識別Event的速度非常快，以毫秒來計算。它會在圖片上傳、應用內活動、點擊網站或聯網設備的輸出等事件發生后的幾毫秒內，開始運行代碼，分配合適的計算資源來執行這個行動。它可以自動擴展到數百萬個請求，如需要可跨越多個可用區。根據AWS Lambda是按計算時間收費，計費單位為100毫秒，可以輕松地把應用從每天幾次請求擴展到所需要的任何規模的請求

而在此之前不久，2014年10月22日，谷歌今天收購了實時后端數據庫創業公司Firebase。Firebase聲稱開發者只需引用一個API庫文件就可以使用標準REST API的各種接口對數據進行讀寫操作，只需編寫 HTML＋CSS＋JavaScrip前端代碼，不需要服務器端代碼（如需整合，也極其簡單）。Firebase是一個實時應用平臺，它可以為幾乎所有應用的通用需求提供支持，包括數據庫、API和認證處理。數據庫的特點是基于NoSQL的實時處理能力，并且允許直接存儲JSON文檔。Firebase具有雙向同步的能力，在客戶端側，開發者通過Firebase的客戶端庫來支持典型場景的需求，比如屏幕刷新、離線時數據訪問或者設備重新連接后的再次同步。Firebase對數據存儲容量沒有限制，較高能處理百萬級的并發和TB級的數據傳輸，數據發生更改，同步敏感顆粒度基本達到10毫秒級別。

相對于上兩者，Facebook 在2014年二月收購的 Parse，則側重于提供一個通用的后臺服務。不過這些服務被稱為Serverless或no sever。想到PaaS了是嗎？很像，用戶不需要關心基礎設施，只需要關心業務，這是遲到的PaaS，也是更實用的PaaS。這很有可能將會變革整個開發過程和傳統的應用生命周期，一旦開發者們習慣了這種全自動的云上資源的創建和分配，或許就再也回不到那些需要微應用配置資源的時代里去了。

AWS的Lambda既不是最早，也不是較好，但它仍然是serverless最有影響力的產品，誰讓AWS的用戶多，產品全呢？

Serverless是未來嗎？也許是。

Serverless能決定云計算的勝負嗎？不能。

什么能決定云計算的勝負？

不僅Serverless不能，其他的產品、技術、項目、工具，都不能多帶帶決定云計算的勝負。

從云計算初期的OpenStack和PaaS，到后來的Docker、Kubernets、Mesos、Unikernals，以及最近沸沸揚揚的人工智能，還有大數據分析，IBM甚至宣稱Watson是它的云計算秘密武器，甚至可能即將光大的Serverless，都不能多帶帶決定云計算的勝負。

它們都是優秀的產品、技術、項目、工具，但只是一項產品、技術、項目、工具，它們只能用來更好的服務客戶，開辟新產品和加強已有產品，可以用來建立新業務或新公司。

IBM或谷歌也許能成為人工智能的王者，Docker也許能成為容器的領袖，Cloudera也許能成為大數據的領軍企業，即使如此，這都是另一個領域的事情，是一種應用場景的事情，它們也許能也許不能成就新的行業，但都與云計算基礎服務無關，與IaaS和PaaS無關，與公有云勝負無關。

公司管理者和技術控們：指望拿熱門開源項目，個人賺點錢可以，要讓一個公司鯉魚跳龍門或翻身，沒門，那就不僅僅是你抓的項目名字火不火的問題。

這個世界從來沒有獨門秘籍。改變云計算格局，顛覆云計算市場的，不會是一個獨門技術，也不會是一項秘密產品。

能決定云計算勝負的，仍然是遠見、魄力、耐心。如果已經有了早行者，那就需要持續的創新，來蠶食領先者的優勢。云計算是一個龐大的市場，從來不是一項技術、一個項目、一個產品的事情。

沒有捷徑！

軟件開發技術群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發經驗交流，各種框架使用，外包項目機會，學習、培訓、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進，優化，分布式系統場景定制，與Hadoop有關的各種開源項目，總之就是玩轉Hadoop

QQ群：288410967?