Pivotal和谷歌共建Kubernetes(K8S)生態(上篇)

02-04

谷歌Kubernetes和Pivotal Cloud Foundry的關係可能搞得業界有點混淆。最近還是有不少分析師問我Pivotal的Cloud Foundry如何和谷歌的Kubernetes競爭。我本來以為Pivotal、VMWare和Google三者的公關把這個事情說清楚了。因為聰明的分析師們都看不明白這個事情，所以我百度了一下。我發現所有的中文報道都沒有能夠深刻剖析我們三方的合作邏輯，所以我覺得有必要寫這篇blog。在《Cloud Foundry: 從數字化戰略到實現》的書稿發布前，Pivotal和VMWare和谷歌三方就Kubernetes的合作關係緊鑼密鼓通信中，公司要求高管保密到SpringOne大會召開的時候正式發布，所以我在書稿中不能探討Kubernetes進入Cloud Foundry 2.0版本的邏輯。當媒體和分析師們問及Kubernetes競爭Cloud Foundry的時候，我只能引導他們站在PaaS產業上去推理這裡的商業邏輯。如果站在產業高度上看，一些看似競爭關係實質上作為合作關係更加合理。目前你進入Google雲主頁google.com/Pivotal可以一覽合作關係。

首先，我們先站在Google雲的角度上看。公有雲廠商中谷歌是最早把戰略定位在PaaS雲上的。谷歌當時推出的產品叫做Google Compute Engine(GCE)。這裡可能是因為Google在IaaS層雲和AWS競爭差異化造成的，也有可能是Google和我們的目光一樣，認為PaaS雲是雲計算的新浪潮（具體邏輯參考書第一章第三節《1.3P層雲計算和數字化變革》）。Google Compute Engine（GCE）的首次公開發行是在2012年，而Cloud Foundry(CF)的第一版是在2011年亮相。當其他的雲廠商都在賣虛擬伺服器的時候，GCE和CF站出來說開發人員不需要關心虛擬伺服器而只需要關心自己的應用。雙方在那個時候在舉起一個上萬億美元的市場信念可謂是形影相弔。兩個寂寞的視野家雖然彼此惺惺相惜，但生意歸生意，各自照顧各自的投資人和客戶利益，還不構成充分的合作邏輯。在谷歌推進PaaS戰略的過程中，以Docker為主容器技術在碼農中火了起來（我建議分析師們在這個年代一定要關心碼農的心情走向）。容器技術對於Google和VMWare當然不是什麼難的技術，但是難點在於容器的編排和調度(分散式計算機的問題）。所以Google做了一個Kubernetes（縮寫為K8S，意思是K後面跳過8個字母到S。這裡扯遠一下下聊聊矽谷的縮寫壞習慣。矽谷的聰明人有一個壞習慣就是喜歡把一個長單詞用首字母+跳過的字母數來進行縮寫，目的是讓爺爺奶奶們讀不懂。例如亞馬遜的Algorithms被寫成A9，如下面動畫所示。）

回到正題上。因為K8S的先進性和容器技術的火爆，Google雲的「K8S+Docker」在公有雲市場取得了巨大的反響。但是Google的基因是公有雲和消費者市場，如何把「K8S+Docker」推向500強帝國企業不是Google的特長。另外企業軟體和互聯網軟體的還有一個重大差別，就是如何安裝、管理、維護和升級上千個「K8S+Docker「在帝國企業防火牆裡面的部署？Google雲只要維護自己的一個部署，Google雲是去組建一個企業軟體團隊觸及帝國企業群還是物色一個門當戶對的合作夥伴？讀者去Google網站查找的話答案就在第一幅插圖。

中篇我們再切換到故事的另外一個主角Pivotal上看心路歷程。（….to be continued）