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

谷歌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）

作者：Pivotal中国Head冯雷  [如需转载,请注明本文URL
Pivotal和谷歌共建Kubernetes(K8S)生态(上篇)