HQY 一个和谐有爱的空间

 VMware 在面对公有云的冲击的时候，整体表现不错。本文我们来看一下，面临容器云的进攻，VMware 的表现可以打几分。

VMware 在 PaaS 层面占得先机

Cloud Foundry 是由 VMware 在 2011 年发布的第一代 PaaS 平台。Cloud Foundry 是一个开源项目。Cloud Foundry 不仅仅在开源领域非常火热，而且被很多云平台服务商看中，作为云平台 PaaS 服务提供。在当年，虽然 PaaS 本身尚未成熟，但是作为几乎是唯一的生产可用的落地产品，Cloud Foundry 当时可谓是风光无量。

同时，VMware 在 2009 年收购了 SpringSource。Spring 是 Java 领域的重量级平台。由此，我们看到其实 VMware 在很早的时候，就开始 PaaS 层面的布局。一切似乎都向着好的方向发展。

Pivotal 错失良机

事情的转折发生在 2013 年。Pivotal 成立了。Pivotal 是由 EMC、VMware 和 GE 联合成立的公司。核心的产品就是 VMware 的 Cloud Foundry、Spring 以及 EMC 的 Greenplum。

在 Pivotal 的时代，Cloud Founrdy 的创新乏善可陈。以至于在 2019 年，VMware 收购 Pivotal 的时候，Cloud Foundry 几乎没有什么太大的变化。

其实，Cloud Foundry 本来就使用了容器技术，名字叫做 Garden 和 Diego。Garden 是容器运行时，Diego 是编排和调度平台。理念和 Docker/Kubernetes 其实是类似的。但是非常遗憾的是，Cloud Foundry 既没能持续引领这个时代，也没能和 Kubernetes 平台融合。Cloud Foundry 的先发优势，在几年之后，丧失殆尽。

2019 年，VMware 收购 Pivotal 之后，企图重新基于 Kubernetes 构建 Cloud Foundry 新版本。但是，这注定是没有意义的。当你错过了，Kubernetes 的生态已经非常蓬勃的时候，你已经没有追赶上的可能了。事实上，Cloud Foundry on Kubernetes 产品也最终没有发布。

VMware 在容器云层面的努力

• 2015 年，VMware 发布了 vSphere Integrated Containers (VIC)。VIC 支持用户在 vSphere 上面创建容器，并且兼容 Docker 的生态。
• 2017 年，VMware 和 Pivotal 合作，推出了 Pivotal Container Service (PKS)，这是一个企业级的 Kubernetes 平台。
• 2018 年，VMware 收购了 Heptio，这是一家由 Kubernetes 创始人创办的公司，收购之后 VMware 基于 Heptio 的技术发布了 Tanzu Kubernetes Grid Multicloud (TKGM)。
• 2020 年，VMware 发布 vSphere 7.0，其中最重要的新功能之一就是 Tanzu Kubernetes Grid Service (TKGS)。TKGS 是内嵌在 vSphere 中的 Kubernetes 平台。

读到这里，你是不是觉得很混乱，为什么会有这么多产品，有什么区别？ 是的。作为 VMware 的员工，我也曾经很混乱。其实，这也反映了 VMware 容器战略层面的混乱。 通过我自己的观察和分析，混乱的原因包括：

1. 在 Dell 集团下面，VMware 的自主权不足，必须要和 Pivotal 合作开发容器云平台。
2. Heptio 团队和 vSphere 团队没能很好的融合，其理念的不同，导致了 TKGS 和 TKGM 的架构迥异，但是同时存在。

VMware 容器云解决方案的定型

在经过几年的混乱之后，我们看到：TKGS 最终胜出。这是合理的结果。 主要原因是：

1. VMware 的目标是：“用户在应用转型之后，其 Kubernetes 集群仍然运行在 vSphere 上”。所有运行在物理服务器的 Kubernetes 方案都是 VMware 的敌人，VMware 当然自己更不会去做。
2. 只有用户认可将 Kubernetes 运行在虚拟化平台上，VMware 才有竞争优势。 也就是说，离开了 vSphere，VMware 在容器云方案层面，几乎没有任何优势。

当然，我们也看到 Kubernetes 技术发展对 VMware 有利的方面：

1. Kuberentes 平台的运维从应用团队逐步转移到了 IT 基础设施团队。而 IT 基础设施团队天生就对 VMware 比较熟悉和友好。
2. 当用户在使用初期，需要的资源不多，可能也就几台 VM 就够了，这时候充分利用现有的 vSphere 集群的资源，似乎是一个更加合理的方案。
3. Kuberentes 多集群的需求，在大客户那边，逐步变得强烈；同时，在以采购应用为主的客户那边，采用多集群对不同开发商的应用进行隔离也是重要需求。这对于虚拟化平台是有利的。为了加强 Kubernetes 多集群管理功能，VMware 还开发了 Tanzu Mission Control（TMC） 产品。详细内容请大家参看我之前的文章《你究竟需要多少个 Kubernetes 生产集群？》

VMware 始终无法忽视的问题

虽然我们看到 VMware 容器云解决方案的最终定型，但是我们始终无法回避一个问题：价格。

使用 VMware TKGS 方案的前提条件是需要 vSphere 的软件授权。vSphere 的软件授权并不便宜。而且在一台物理服务器上，通常也运行不了几个 Kubernetes Nodes。而如果用户选择物理服务器部署 Kubernetes 集群，是不需要这笔额外的费用的。特别的是：在 Kuberentes 集群的设计中，其实 vSphere 的很多高级功能（比如 vMotion、DRS）并没有太大的用处。

所以，当用户和我们讲：“我认可你说到的所有优势，但是我觉得不够支撑 vSphere 授权的价格”，我无力解释。 当然对于“值不值这个价格”，每个用户的价值判断都可能不太一样，就如同有人认可高档餐厅的服务和对应的价格，也有人觉得普通餐厅更有性价比。

小结

VMware 对于 Kubernetes 是很纠结的。所谓的“拥抱Kuberentes”，我理解更多的也只是一个商业话术罢了。但是，VMware 显然也知道技术的发展是不可阻挡的。在经历了前期的混乱之后，最终推出 “TKGS + TMC” 的解决方案，我认为这是一个不断加深理解和尝试之后，形成的结果。 这当然不是最好的结果，但是在当前来看，也许就是最好的结果了。我唯一觉得遗憾的是 Cloud Foundry 本来或许可以领导一个时代，但是最终却是 “起了个大早，赶了个晚集”。

也许在一些年以后，特别是当用户的 Kuberentes 集群不断扩大之后，从成本的角度，Tanzu 的用户会迁移 Kuberentes 集群到物理服务器。

也许在一些年以后，用户的大部分应用都运行在 Kubernetes 上面。而运行在 vSphere 虚拟机中的应用越来越少，就如同现在运行在小型机上面的应用越来越少。当然这可能需要的时间会更长一些，毕竟改写应用是需要成本的。

也许... 也许 Kuberentes 也会被新的技术取代。不对。Kuberentes 一定会被取代，这只是时间问题。毕竟，IT 技术的发展一直滚滚向前，从不停歇。不是吗？

写在最后

这个系列的最后一篇文章也写完了。我知道，VMware 有很多的产品我都没有提到，比如 Horizon、Workspace ONE、vRealize、AVI、VeloCloud、SRM ...  这些当然都是很优秀的产品。请原谅我学识有限，精力有限，无法一一讲述。

VMware 是一家伟大的公司，原文作者以能够在这家公司工作 11 年，感到自豪。在此期间，学习到了很多知识，获得了成长，同时也收获了友谊。在长期的合作中，和很多客户和合作伙伴，也成为了朋友。从他们身上学习到了很多。在文章的最后，向他们表示感谢！ 

同时，真心希望，VMware 在博通的领导之下，发展越来越好！

推荐本站淘宝优惠价购买喜欢的宝贝:

本文链接：https://hqyman.cn/post/6955.html 非本站原创文章欢迎转载，原创文章需保留本站地址！

休息一下~~