但其實docker半個老古董。
Docker這半個老古董，掀起了第二波從眾，而且想取巧并彎道超車的浪潮
沒錯，第二波終于來了。
因為不但搞OpenStack沒能搞掂公有云，不搞OpenStack的也沒能搞掂公有云。得有點新東西出來。
我們先從看看Docker有多老開始?，F(xiàn)在看到的docker的起源都不能算起源，只能說出生。其實docker也有老祖先七大姑八大姨的。
任何東西都能追溯到老祖先，虛擬化還能追溯到70年代的大型機呢。那個是有點牽強了，但是docker的直系親屬那也是夠老的。
遠房的親戚就不說了，新生代的KVM都6、7年的歷史了，老一代的Xen和qemu從2003年算起都十二三年的歷史了。在IT行業(yè)，10年已經(jīng)很久了。
但docker的近親，歷史也不短，甚至有的更久。docker它爸lxc從2006年開始開發(fā)，到2008年發(fā)布0.1.0版本，docker直接間接chroot、cgroup、namespaces、libcontainer使用的其他組件的歷史當然也不會比LXC短。它叔叔linux-vserver2003年就已經(jīng)發(fā)布了1.0版本，這是基于內(nèi)核態(tài)隔離的容器。
它還有眾多表兄弟Cloudfoundry Warden、BSD jails、Aix workload partitions、iCorevirtual accounts、Sandboxie、Virtuozzo等等，其中Virtuozzo、openvz和solaris container歷史都在十年以上。
關(guān)注虛擬化和IDC的，有些docker的親戚應該是很熟悉的。這回又提到IDC了，云計算真實上輩子就跟IDC糾纏在一起。收費的Virtuozzo、免費的openvz，那是云計算和云主機出現(xiàn)之前，Xen和KVM出現(xiàn)之前，搞VPS的利器。10年前VPS賣的多火，被視為虛擬主機的升級版。
Openvz是Virtuozzo容器技術(shù)的linux版，LXC是Openvz為了融入內(nèi)核開發(fā)的對應版，開發(fā)者大部分是同一批人。LXC及周邊工具就是現(xiàn)在Docker的重要組成部分。
Docker出現(xiàn)也就5,6年，但它的大部分身體都出現(xiàn)差不多10年了，你說它是不是半個老古董呢？
Docker本身大家都很熟很熟了，不用贅言。不過經(jīng)常有人拿Docker和xen、kvm支持的虛擬機對比，說占用體積小、啟動速度快，不是一個層級的東西好嘛，一個在操作系統(tǒng)之上，一個在操作系統(tǒng)之下，不贅言了。Docker當然也不能和LXC等linux容器對比，都是用的同一系列核心工具，只是管理層不同而已。
Docker在2013年底，2014年初，突然吸引了眾人的目光，并在2014年2015年集萬千寵愛于一身，就如前兩年的openstack一樣。
回到docker誕生的年代，2010年，幾個年輕人在舊金山成立了一家做 PaaS 平臺的公司-dotcloud。大家現(xiàn)在都知道heroku，也是PaaS型，而且，也用到了容器，可能是LXC吧。當然不是新堆棧PaaS，而是傳統(tǒng)堆棧PaaS。這和heroku一樣，為開發(fā)人員提供操作系統(tǒng)、通用庫、特定語言的運行環(huán)境，應用的部署、管理、監(jiān)控等。
dotCloud 把需要花費大量時間的重復性工作，抽象成組件和服務，如規(guī)范容器的格式、便利容器的生命周期管理等，方便開發(fā)者管理和監(jiān)控自己的應用。
正如我在《云計算時代》一書中所言，新堆棧PaaS離開發(fā)者現(xiàn)有技能太遠，傳統(tǒng)堆棧PaaS離現(xiàn)有堆棧太近。不管哪種，都擋住了開發(fā)者掌控一切的意愿。所以，PaaS多年來雖然獨立作為一類云服務，并沒有足夠大的市場。
雖然dotCloud 在2011年初拿到了1000萬美元的融資，但這個市場本沒有那么大，也沒有快速的增長，容納不下太多的企業(yè)。也沒有干過heroku、engineyard等公司，自然前景不妙。
dotCloud 的創(chuàng)始人 Solomon Hykes 把大伙召集到一起，大家琢磨了一下，商業(yè)是沒戲了，那也要搞一把非商業(yè)的事情，把我們在容器上的工作起名docker開源出來。能不能把競爭對手干掉不好說，希望是挺渺茫，但是起碼能在社區(qū)留個名！萬一，開放開源能夠搞成更大的勢頭，公司還能起來呢。
是不是和RackSpace當初搞OpenStack有幾分相像？狗急了還要跳墻呢，絕處逢生不是不可能。所謂堅持，耐心，就是這個意思。只是這是一條高風險高收益的路罷了。
LXC，包括openvz，在2013年之前，可不只是heroku等paas公司在用，有些公司內(nèi)部都在使用，甚至包括我在內(nèi)的一些公有云從業(yè)者也慎重考慮過用容器作為公有云的基礎(chǔ)。
當然，還真有這么干的，Joyent，大概是除了AWS干公有云最早的了吧，可能比RackSpace還早點，就是基于solaris zone賣云主機的。Joyent的技術(shù)骨干是從SUN出來的，精通solaris，他們整了一個基于solaris的精簡內(nèi)核，專門用來跑zone，類似于coreos，叫做smartOS，基于這個做出了私有云軟件SmartDataCenter。
說這些可能沒幾個人知道，但是鼎鼎大名的node.js很多人熟悉，就是Joyent開發(fā)維護的。
沒錯，LXC和openvz用在企業(yè)內(nèi)部是很好的，非常好。但是限于LXC當時的管理工具欠缺，并沒能大規(guī)模流行起來。它需要一個契機。這個契機就是docker，docker解決了LXC的管理問題。
電視劇總是那么相似，相遇、離別、重逢，受苦受難、遇到高人、報仇雪恨，IT圈的故事也逃脫不了這樣的情節(jié)。Docker的故事，真的和OpenStack，包括此前的Linux等其他開源軟件，有幾分相似。
dotCloud把自己在容器上的工作成果docker開放開源了，開發(fā)者和小公司雀躍了：又來一個餡餅啊。這個餡餅解決了一些問題，讓其他人和開發(fā)者免除了管理和開發(fā)工作量，這是次要的。
更重要的是，后來參與的開發(fā)者、小公司、大公司對docker的期待，遠不止解決容器本身的管理問題，也不只是因為有一批人喜歡而從眾，還有一個很多人很多公司沒有說出的理由：容器是未來，干掉現(xiàn)在的私有云和公有云。
Docker 如此受歡迎，2013年10月 dotCloud 公司更名為 Docker 公司。2014年8月 Docker把平臺即服務的業(yè)務dotCloud出售給位于德國柏林的平臺即服務提供商cloudControl，2016年初 dotCloud被cloudControl關(guān)閉。而Docker公司開始全身心運營docker社區(qū)，并開展docker商業(yè)化。
Docker 迅速成長為云計算相關(guān)領(lǐng)域最受歡迎的開源項目，Amazon、Google、IBM、Microsoft、Red Hat 和 VMware 都表示支持 Docker 技術(shù)或準備支持。
據(jù)說，有 Linux 的地方，就可以運行 Docker。Mac上也可以，Windows上都有直接運行docker的Windows Docker 和 Nano Server，當然，這已經(jīng)是windows版的了。
截止2016年初，Docker獲得5輪1.8億美元融資，推出了docker hub、docker trusted registry、dockertutm等產(chǎn)品，試圖控制docker容器的注冊、管理。在2015年上半年與openstack的論戰(zhàn)之后，雙方握手言和，以openstack支持docker管理告終。
Docker當然不甘心只是一個工具軟件，也是要做產(chǎn)品、平臺的，拿投資人的錢可不能做公益做開源啊。凡是有威脅的就要干掉，或者收掉。于是Docker收購Unikernels。
Docker為何收購Unikernels？既是看好，更是感到威脅
容器作為虛擬化技術(shù)的一種，在云計算出現(xiàn)之前就出現(xiàn)了。之所以在2014年前后流行，是因為大家需要一種與硬件虛擬化更輕量級的技術(shù)，來有效運轉(zhuǎn)私有的基礎(chǔ)設(shè)施。這個私有的，既可以在自家機房里也可以在公有云上。
在私有的私有的基礎(chǔ)設(shè)施上，至少某些應用場景，Docker應為其輕量級，應用啟動更為迅速，資源利用更為高效。但是，循著這個思路，Unikernels更進了一步。
我們先來看看怎么回事。
從操作系統(tǒng)誕生以來，它就扮演了一個應用和硬件之間的平臺的角色，提供對硬件的控制。除了操作系統(tǒng)內(nèi)核和基本的控制臺，還有軟件開發(fā)接口、語言運營時環(huán)境、語言庫、輸入輸出設(shè)備控制，也需要支持各種古老的和新興的硬件標準。它需要支持多用戶、多進程、多設(shè)備并發(fā)。
雖然操作系統(tǒng)的的用途各異，有桌面的、內(nèi)部IT系統(tǒng)的、有面向網(wǎng)絡的，但操作系統(tǒng)的架構(gòu)和模塊基本相同，一致沒有大的改動。但在上世紀90年代后期，Hypervisor被引入了主流的操作系統(tǒng)。Hypervisor運行于硬件之上，能支持多個虛擬機運行多個不同的操作系統(tǒng)。但這一變化，并未對操作系統(tǒng)的設(shè)計產(chǎn)生大的影響。每一個虛擬機仍然運行著一個傳統(tǒng)的操作系統(tǒng)。
但是當Hyperfisor推動了云時代的到來后，通用操作系統(tǒng)的局限就更明顯了。在云環(huán)境中，由于規(guī)模更大，負載被明顯鳳城了不同的類型：web服務器負責處理網(wǎng)絡請求，數(shù)據(jù)庫服務器負責數(shù)據(jù)庫的運行和數(shù)據(jù)庫訪問，等等。這些服務器可能永遠都用不上顯示器、多用戶、多進程。這些場景下的VM和OS的任務很明確，就是提供最好的存儲、計算、網(wǎng)絡性能。
開發(fā)者們開始質(zhì)疑操作系統(tǒng)的的設(shè)計和架構(gòu)：為什么一個web server 上要安裝它從來用不到的軟件？其實在此之前，Windows服務器就遇到過類似的問題。我們只需要能快速擴展和收縮VM的規(guī)模，VM約精簡越輕量級越有利于這種彈性。但由傳統(tǒng)操作系統(tǒng)構(gòu)成的VM，只能勉強完成這個任務。
Docker所代表的容器恰逢其時。因為基礎(chǔ)技術(shù)早已就緒，流行很快。因為能在同一個操作系統(tǒng)上快速運行多個隔離的輕量級的，容器基本解決了上述疑問。容器提供了應用程序所需要的一切，除了共用的操作系統(tǒng)內(nèi)核，它封裝了運行時環(huán)境、框架和庫、代碼、配置和相關(guān)的依賴。
容器大大削減了操作系統(tǒng)作為一個全能平臺所承擔的角色。容器之下的操作系統(tǒng)這時只需要承擔一個飛航輕量級的角色：啟動和控制容器。這時的操作系統(tǒng)更為專業(yè)化，而容器承擔了運行各種不同場景所需資源的角色。
這種趨勢催生了容器的Hypervisor的產(chǎn)生：CoreOS,RancherOS,Redhat Atomic Hosts,SnappyUbuntu Core,Microsoft Nano。他們是為了支持在其上運行容器而存在，沒有其他的任務，已經(jīng)非常精簡。甚至Hypervisor之上的容器，有人又將其區(qū)分為操作系統(tǒng)容器和應用容器，應用容器就是只為單一應用為目標的容器。
到這里，微服務（MicroService）終于可以見天日了，終于能夠使用了，而所謂的SOA、Mashable是不是能夠換發(fā)新的光彩呢？
但這種精簡、輕量級還沒有到此為止，Unikernals出現(xiàn)了。在2014年初就出現(xiàn)了，那時docker剛剛開始崛起。
Unikernals將這種最小化操作系統(tǒng)的理念往前進一步推進。它是一個定制的操作系統(tǒng)，轉(zhuǎn)為特定的應用程序的運行而編譯。
因此，開發(fā)者能夠創(chuàng)建一個極度精簡的OS，只包含應用和它所需的操作系統(tǒng)組件。Unikernals是單用戶、單進程、單任務的定制操作系統(tǒng)，它在編譯時去除了所有不需要的功能，但包含了一個軟件運行所需的全部堆棧：OS內(nèi)核、系統(tǒng)庫、語言運行時環(huán)境、應用，這些被編譯成一個可啟動的VM鏡像，直接運行在標準的hypervisor上。
Unikernals讓操作系統(tǒng)之上的容器又變成了一個操作系統(tǒng)，不過這是一個重新吧便宜的極為緊湊的，直接運行在hypervisor而不是精簡的通用操作系統(tǒng)上的操作系統(tǒng)。Unikernel有著更小的尺寸，更小的可攻擊面，啟動時間也以毫秒計。Unikernals的論文在這里：https://queue.acm.org/detail.cfm?id=2566628。
不過，和docker一樣，靈活帶來的伴生問題，就是管理、監(jiān)控、回溯、審計，有運維工程師說，docker就是運維的噩夢，那Unikernals可能是運維和開發(fā)者的噩夢？為啥，因為對應用改一行代碼要重新編譯整個鏡像并部署，無法對一個Unikernals實例打補丁，也就是說Unikernals的實例是靜態(tài)的。
Unikernals的例子包括MirageOS、Clive、OSv，目前都跑在Xen Hypervisor上。它有多小呢？一個MirageOSDNS鏡像是200KB，而一個目前全球90%DNS使用的開源DNS服務器BIND鏡像是400MB。而MirageOS DNS鏡像的性能據(jù)稱比BIND好45%。
咦？這不是嵌入式系統(tǒng)嗎？Unikernals當然可以編譯出鏡像，運轉(zhuǎn)在低功耗的設(shè)備上。如果Unikernals被移植到ARM平臺上，開發(fā)者就可以編譯出運行在ARM設(shè)備的hypervisor上的鏡像。這將讓嵌入式應用的開發(fā)更為容易。
那么，看起來，Unikernals雖然現(xiàn)在更像一個即可玩具，但是，不可否認，Unikernals有代替容器和虛擬機的可能，至少在某些場景下。既然容器比虛擬機在某些場景下更好，為什么更精簡的Unikernals就不能代替容器和虛擬機呢？
有可能。而且這個理念和Docker代表的容器理念相符。于是，Docker收購了它。大家一起玩，一起干掉虛擬機。
Docker看起來無敵，前景光明。但是，道路還是曲折的。
大佬們是想干掉私有云和公有云的啊，你Docker公司守著這個熱門技術(shù)不放，控制的緊緊的，我們怎么玩？不光是大佬，創(chuàng)業(yè)公司也不干啊。
首先發(fā)難的是CoreOS和谷歌。
CoreOS反水，Kubernetes和Mesos把docker打回工具原型
CoreOS首先不干了。
CoreOS原本是Docker初期的鐵桿盟友，CoreOS可以說就是為docker而生的linux，它的唯一任務就是管理好docker。但是隨著docker開始商業(yè)化，docker對鏡像格式和代碼收緊了控制，甚至建立開放平臺存儲docker鏡像和認證，當然，還發(fā)布了docker管理工具。
那CoreOS的位置在哪里？當然，理由還是要像樣一點的：docker的鏡像格式不夠靈活，工具鏈太龐大，我們要靈活而精簡的東西。
于是CoreOS自己搞了一個容器：Rocket。本來嘛，大家都是基于LXC等工具的，這些工具都是開源開放，而且CoreOS也搞容器管理的，新搞個格式和管理工具還不是手到擒來。
當然，雙方都承認，docker和rocket不是直接競爭關(guān)系。Docker是一個產(chǎn)品，并正在成為一個平臺。Rocket只想做一個容器管理的組件。但是，雙方還是分道揚鑣了。
CoreOS一個人可沒這么大的氣勢，背后還有谷歌撐腰。Rocket很快被Kubernetes支持。
Kubernetes的靈感來源于Google的內(nèi)部borg系統(tǒng)，吸收了包括Omega在內(nèi)的容器管理器的經(jīng)驗和教訓。2014年6月谷歌宣布kubernetes 開源。谷歌想靠容器翻身呢？怎么能讓另一個商業(yè)云公司控制最流行的容器。
Kubernetes算是一個與docker平臺競爭的容器管理工具，自然首先支持docker，但是也支持競爭對手rocket。
但是Kubernetes也有一個潛在對手-Mesos。Mesos比Kubernetes出現(xiàn)得早，而且兩者都深受谷歌的數(shù)據(jù)中心管理你項目Borg和Omega的影響。問題是，Mesos不是谷歌自家的，雖然屬于Apache項目，但仍被商業(yè)公司Mesosphere，也是Mesos重要維護者主導。Mesos被稱為數(shù)據(jù)中心操作系統(tǒng)，軟件定義數(shù)據(jù)中心的典范。
Mesos既是計算框架也是一個集群管理器，是Apache下的開源分布式資源管理框架，它被稱為是分布式系統(tǒng)的內(nèi)核，可以運行Hadoop、MPI、Hypertable、Spark。使用ZooKeeper實現(xiàn)容錯復制，使用LinuxContainers來隔離任務，支持多種資源計劃分配。
Mesos使用了與Linux內(nèi)核相似的規(guī)則來構(gòu)造，僅僅是不同抽象層級的差別。Mesos從設(shè)備（物理機或虛擬機）抽取 CPU，內(nèi)存，存儲和其他計算資源，讓容錯和彈性分布式系統(tǒng)更容易使用。Mesos內(nèi)核運行在每個機器上，在整個數(shù)據(jù)中心和云環(huán)境內(nèi)向應用程序（Hadoop、Spark、Kafka、Elastic Serarch等等）提供資源管理和資源負載的API接口。
Mesos也不是也不是沒有隱憂，Apache yarn似乎有一統(tǒng)分布式計算之勢，MapReduce，Spark，Storm，MPI，HBase都在向yarn上遷移。當然，好在Mesos不僅僅是做分布式計算的框架。
Mesos也起源于Google的數(shù)據(jù)中心資源管理系統(tǒng)Borg。Twitter從Google的Borg系統(tǒng)中得到啟發(fā)，然后就開發(fā)一個類似的資源管理系統(tǒng)來幫助他們擺脫可怕的“失敗之鯨”，后來他們注意到加州大學伯克利分校AMPLab正在開發(fā)的名為Mesos的項目，這個項目的負責人是Ben Hindman，Ben是加州大學伯克利分校的博士研究生。后來Ben Hindman加入了Twitter，負責開發(fā)和部署Mesos?，F(xiàn)在Mesos管理著Twitter超過30,0000臺服務器上的應用部署。
Borg的論文2015年四月才發(fā)布：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。這一回，谷歌論文發(fā)晚了，雖然也很有價值，但可能沒有三大論文那么有影響力。
2014年7月，Mircrosoft、RedHat、IBM、Docker、 CoreOS、Mesosphere 和Saltstack 加入kubernetes。
2015年1月，Google和Mirantis及伙伴將kubernetes引入OpenStack，開發(fā)者可以在openstack上部署運行kubernetes應用。
2015年7月，Google正式加入OpenStack基金會，Kubernetes的產(chǎn)品經(jīng)理CraigMcLuckie宣布Google將成為OpenStack基金會的發(fā)起人之一，Google將把它容器計算的專家技術(shù)帶入OpenStack,成一體提高公有云和私有云的互用性。
同時，谷歌聯(lián)合linux基金會及其他合作伙伴共同成立了CNCF基金會( Cloud NativeComputing Foundation)，并將kuberentes 作為首個編入CNCF管理體系的開源項目。
來，我們來看一下發(fā)起人：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, VMwareand Weaveworks。
到此是不是大團圓了？所有跟容器有點關(guān)系的都來了。谷歌加入了OpenStack基金會，openstack上可以部署運行kubernetes，OpenStack支持docker，Mesos支持docker和kubernetes。大家互相都支持，誰能發(fā)展好，各自努力吧。這關(guān)系夠亂的。
但是，容器的另外兩個大玩家-亞馬遜和微軟，沒有到場。沒錯，容器界就是要掀翻現(xiàn)有的云計算格局，當然不能讓云計算老大和老二進來了。
谷歌糾集了一幫小兄弟，誓要利用容器浪潮，干翻亞馬遜aws和微軟azure。當然，谷歌也沒有奔到準備靠一招制勝，暗戰(zhàn)還有另一個戰(zhàn)場：Serverless。
Serverless是云計算的決勝負戰(zhàn)場？
2014年11月14日，亞馬遜AWS發(fā)布了新產(chǎn)品Lambda。當時Lambda被描述為：一種計算服務，根據(jù)時間運行用戶的代碼，無需關(guān)心底層的計算資源。從某種意義上來說，Lambda姍姍來遲，它更像S3，更像云計算的PaaS理念：客戶只管業(yè)務，無需擔心存儲和計算資源。
比如你要架構(gòu)一個視頻服務，你需要用一堆服務器，設(shè)計出一套上傳、解碼、轉(zhuǎn)碼的架構(gòu)。但是，可能這套系統(tǒng)99%的時間都是空閑的。而使用一個Lambda function，你就不需要操心服務器和這套架構(gòu)，當aws探測到用戶定義的時間，比如用戶上傳了一個視頻文件，Lambda自動運行響應的程序，結(jié)束后關(guān)閉程序。為客戶生了時間和金錢。
Lambda識別Event的速度非?？?，以毫秒來計算。它會在圖片上傳、應用內(nèi)活動、點擊網(wǎng)站或聯(lián)網(wǎng)設(shè)備的輸出等事件發(fā)生后的幾毫秒內(nèi)，開始運行代碼，分配合適的計算資源來執(zhí)行這個行動。它可以自動擴展到數(shù)百萬個請求，如需要可跨越多個可用區(qū)。根據(jù)AWS Lambda是按計算時間收費，計費單位為100毫秒，可以輕松地把應用從每天幾次請求擴展到所需要的任何規(guī)模的請求
而在此之前不久，2014年10月22日，谷歌今天收購了實時后端數(shù)據(jù)庫創(chuàng)業(yè)公司Firebase。Firebase聲稱開發(fā)者只需引用一個API庫文件就可以使用標準REST API的各種接口對數(shù)據(jù)進行讀寫操作，只需編寫 HTML＋CSS＋JavaScrip前端代碼，不需要服務器端代碼（如需整合，也及其簡單）。
Firebase是一個實時應用平臺，它可以為幾乎所有應用的通用需求提供支持，包括數(shù)據(jù)庫、API和認證處理。數(shù)據(jù)庫的特點是基于NoSQL的實時處理能力，并且允許直接存儲JSON文檔。Firebase具有雙向同步的能力，在客戶端側(cè)，開發(fā)者通過Firebase的客戶端庫來支持典型場景的需求，比如屏幕刷新、離線時數(shù)據(jù)訪問或者設(shè)備重新連接后的再次同步。Firebase對數(shù)據(jù)存儲容量沒有限制，最高能處理百萬級的并發(fā)和TB級的數(shù)據(jù)傳輸，數(shù)據(jù)發(fā)生更改，同步敏感顆粒度基本達到10毫秒級別。
相對于上兩者，F(xiàn)acebook 在2014年二月收購的 Parse，則側(cè)重于提供一個通用的后臺服務。不過
這些服務被稱為serverless或no sever。想到PaaS了是嗎？很像，用戶不需要關(guān)心基礎(chǔ)設(shè)施，只需要關(guān)心業(yè)務，這是遲到的PaaS，也是更實用的PaaS。這很有可能將會變革整個開發(fā)過程和傳統(tǒng)的應用生命周期，一旦開發(fā)者們習慣了這種全自動的云上資源的創(chuàng)建和分配，或許就再也回不到那些需要微應用配置資源的時代里去了。
AWS的Lambda既不是最早，也不是最好，但它仍然是serverless最有影響力的產(chǎn)品，誰讓AWS的用戶多，產(chǎn)品全呢？
Serverless是未來嗎？也許是。
Serverless能決定云計算的勝負嗎？不能。
什么能決定云計算的勝負？
不僅Serverless不能，其他的產(chǎn)品、技術(shù)、項目、工具，都不能單獨決定云計算的勝負。
從云計算初期的OpenStack和PaaS，到后來的Docker、Kubernets、Mesos、Unikernals，以及最近沸沸揚揚的人工智能，還有大數(shù)據(jù)分析，IBM甚至宣稱Watson是它的云計算秘密武器，甚至可能即將光大的Serverless，都不能單獨決定云計算的勝負。
它們都是優(yōu)秀的產(chǎn)品、技術(shù)、項目、工具，但只是一項產(chǎn)品、技術(shù)、項目、工具，它們只能用來更好的服務客戶，開辟新產(chǎn)品和加強已有產(chǎn)品，可以用來建立新業(yè)務或新公司。
IBM或谷歌也許能成為人工智能的王者，Docker也許能成為容器的領(lǐng)袖，Cloudera也許能成為大數(shù)據(jù)的領(lǐng)軍企業(yè)，即使如此，這都是另一個領(lǐng)域的事情，是一種應用場景的事情，它們也許能也許不能成就新的行業(yè)，但都與云計算基礎(chǔ)服務無關(guān)，與IaaS和PaaS無關(guān)，與公有云勝負無關(guān)。
這個世界從來沒有獨門秘籍。改變云計算格局，顛覆云計算市場的，不會是一個獨門技術(shù)，也不會是一項秘密產(chǎn)品。
能決定云計算勝負的，仍然是遠見、魄力、耐心。如果已經(jīng)有了早行者，那就需要持續(xù)的創(chuàng)新，來蠶食領(lǐng)先者的優(yōu)勢。云計算是一個龐大的市場，從來不是一項技術(shù)、一個項目、一個產(chǎn)品的事情。
沒有捷徑。
微信公眾號techculture
