对于急于进入云端的首席信息官来说，VMware只是做了他们最好的朋友。不，VMware并不只是发布了一个神奇的让他们像谷歌一样运行的盒子里的云。这曾经被称为“OpenStack”，而这在很大程度上是一个失败。相反，VMware重新设计了vSphere，里面有Kubernetes(称为Project Pacific)，就像VMware高级主管jared roosoff在接受采访时说的那样，“500，000家企业数据中心一夜之间得到了Kubernetes和一名训练有素的管理员的员工”。

或者，换句话说：那7000万vSphere工作负载？有了太平洋项目，他们就变成了Kubernetes的工作负载。这一举措中最有趣的部分可能是它如何使企业首席信息官能够以自己的方式拥抱云。

请参阅：如何构建成功的云工程师生涯（免费PDF）（TechRepublic）

但首先，让我们明确：项目太平洋是一种很酷的技术。由于ROSOF已写入：

Project Pacific是以Kubernetes为核心控制平面的vSphere的重新架构.对于开发人员来说，ProjectPacific看起来像一个Kubernetes集群，他们可以使用Kubernetes声明性语法来管理云资源，比如虚拟机、磁盘和网络。对于IT管理员来说，ProjectPacific看起来像vSphere--但是它具有管理整个应用程序的新功能，而不是总是处理组成它的单个VM。

很酷，对吧？掩埋在这三种信息中，有三个重要的要点：

vSphere被转换为Kubernetes本机平台。开发人员获得了很好的新用户体验，同时vSphere继承了Kubernetes生态系统。在开发人员看来，它的外观和感觉都很像Kubernetes，但对于Ops人员来说，它就像vSphere。

以应用为中心的管理意味着企业可以作为一个整体来管理应用程序。如果一个应用程序是50个组件，他们仍然可以管理它作为一个单一的对象。

它都是在基础设施(大多数)企业已经具备的基础设施上工作的。换句话说，他们不需要为云本地应用建立一个堆栈，为虚拟化应用构建另一个堆栈，这也意味着企业不需要对整个团队进行再培训。

VMware在某种程度上构建了一个开放的云平台。在某些方面，这正是OpenStack所期望的，但失败了。OpenStack失败的原因之一，以及ProjectPacific有这么多希望的原因之一，是它没有试图替换公共云。相反，在他们看来，这是一个理想的入口。

推动VMware的人们，在他们兴奋的时候，他们会说：“我们所做的是把Kubernetes自己变成云端”(Rosoff)。但我认为这有点牵强，没有必要考虑到太平洋项目由于其他原因而令人印象深刻，尤其是作为渴望云计算的首席信息官的训练场。

怎么会这样？

考虑这样一个事实：ProjectPacific使企业能够以自己的方式开始自己的云之旅，正如VMware首席工程师(以及Kubernetes的共同创建者)JoeBeda在一次采访中所宣称的那样。云，他指出，实际上是关于其他人为您运行具有一定质量(API驱动、自助服务和弹性)的东西。在黑桃中有这些品质是可能的，但在文化上却完全不能接受它。

要成为云本地人，就必须具备适当的组织知识、流程和文化，以利用这些云特性。这说起来容易做起来难，比达继续说：“公司可以转向‘云’，他们将花费金钱和时间，不会看到他们期望的好处，因为云技术并没有将他们转变为云本土作为一种文化。”

参见：如何建立一个成功的职业生涯作为一个DevOps工程师(免费PDF)(TechRepublic)

进入ProjectPacific，它使企业能够开始一段成为云本土的旅程。他们可以在遗留的Oracle数据库、大型机旁边运行Kubernetes。VMware副总裁基特·科尔伯特(Kit Colbert)告诉我，他们可以开始实验，并按照他们的条件转向云：

[使用项目太平洋]我们可以移动整个客户的应用程序车队，给这些应用程序一些云和一些容器的好处，基本上零-或非常低的成本。当然，他们并没有得到移动到完整的云/云-本机/容器模型的所有好处。但这没关系，因为大多数应用程序可能不需要它。相反，我们允许客户有选择地挑选和选择他们投入了全部[云]努力的应用程序，这些应用真正地区分了他们的业务。

对于那些想要云的首席信息官来说，这种“足够多云”的方法是一个很好的选择，但他们还不能忍受对遗留应用程序的所有重构或重写。太平洋项目很可能给首席信息官一条中间之路，让他们能够将所有应用升级到“准多云”状态，同时加大对那些提供最创新客户解决方案的应用的投入。