【轉】OpenStack和Docker、ServerLess能不能決定雲計算勝負嗎？

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

一、開始於Eucalyptus終結於OpenStack，不只是從衆並且想取巧並彎道超車

    在200八、200九、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是半個老古董。

二、Docker這半個老古董，掀起了第二波從衆並且想取巧並彎道超車的浪潮
    沒錯，第二波終於來了。

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

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

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

    遠房的親戚就不說了，新生代的KVM都六、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。

三、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和谷歌。

四、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。

五、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無關，與公有云勝負無關。

後記：

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

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

    能決定雲計算勝負的，仍然是遠見、魄力、耐心。若是已經有了早行者，那就須要持續的創新，來蠶食領先者的優點。雲計算是一個龐大的市場，歷來不是一項技術、一個項目、一個產品的事情。沒有捷徑！

++補充：

++Serverless表明着將來雲服務正在走向愈來愈分離關注點的趨勢，業務系統不直接與硬件、操做系統和通常容器打交道而是經過一個更高級的容器運行業務系統，業務系統會向容器的管理中心申請各類資源。部署和運維業務再也不過多關心具體硬件與其餘細節，而是關心自身業務與須要的各類資源調配的設置與應用。之後幾乎全部的部署與運維都是針對業務自己，因此之後感受不到服務器的這個具體的硬件實施的存在。這就是亞馬遜定義的「無服務器」架構。

Serverless的架構圖