从旁观者到CTO：我在Cloud Foundry基金会的五年经历

译文
作者：布加迪编译 2020-02-14 09:00:28

开源

云计算 最近我一直在思考Cloud Foundry项目在短短五年内发生了多大的变化。思考结果之一是，自2015年以来开源生态系统和企业计算市场已变得今非昔比。

【51CTO.com快译】最近我一直在思考Cloud Foundry项目在短短五年内发生了多大的变化。

思考结果之一是，自2015年以来开源生态系统和企业计算市场已变得今非昔比。因而，Cloud Foundry及其更广泛的生态系统的共同发展导致将对方推向不同的方向。

同时这也是我职业生涯中过得最快的五年，也是最漫长的五年。

[[314820]]

2009年，Cloud Foundry的最初想法出现在VMware内部。直到2011年4月，该项目才正式宣布。我清楚地记得，该项目做的正是市场所需的事情。宣布的这个平台致力于简化应用程序的开发和部署。在随后几年，我目睹该产品日趋成熟(并数次易主)。2014年，我编写了集成到该平台的第一个服务代理，因此与社区走得更近了一点。

2015年出现了一个年轻的开源社区，它围绕现在开源的Cloud Foundry项目。Cloud Foundry基金会于2015年1月下旬成立。这时候我的角色从社区的旁观者变成了服务者。

底层架构的变化

2015年以后平台发生了很大的变化，无论内部架构还是向使用该平台的开发人员敞开的功能。

Cloud Foundry基金会成立伊始，社区正大刀阔斧地重写平台的底层架构，由最初以Ruby为主的代码库(名为DEA架构)改为基于Go的新架构(名为Diego)。这是很难搞成功的重大架构转变之一。挑战绝非在于新架构本身，而在于转型：对现有架构中新功能的竞争性需求，以及渴望新架构少些不定因素。我在职业生涯中经历过好多这样的转型，而Cloud Foundry社区给我印象最深的一点是它应对这个变化的方式。

当然，开放式协作可能很混乱，不过结果是有条不紊地转型，这给了下游发行版和最终用户组成的生态系统充足的时间来完成转变。从DEA架构正式转向Diego(及其所有子系统)始于2016年11月，当时Diego迎来了1.0版本。这个重要版本向社区表明了两点：它在功能特性上与DEA不相上下，并达到了一些下游发行所希望的250000个容器规模这一目标。

Warden和Garden

与Diego本身发展的同时，负责节点级容器管理的Cloud Foundry组件也出现了重大变化。在DEA架构中，架构的这个部分是名为Warden的组件。Warden至少比Docker早两年问世，但它不是向最终用户敞开的技术。创建Diego时正同时对Warden进行互补性的重写。这项工作名为Garden。

Garden的设计很周到，因为它预料到用户会需要轻松更改代码的最底层细节，以支持新兴的操作系统级容器功能。早在2015年，Cloud Foundry社区就在构建Garden的实现，以同时支持基于Linux的主机和基于微软Windows的主机。能够更改底层的操作系统级容器技术同样使Cloud Foundry平台得以采用Docker捐赠给开放容器项目(OCI)的runC库。实际上，Cloud Foundry项目是第二个采用runC的项目(仅次于Docker本身)，并且使其在整个生态系统的生产级集群中大规模运行。

为什么Diego很重要?

Diego的推出为新功能带来了可能。容器到容器网络和卷服务是Diego进展顺利后最先添加的两大功能。这两种功能可以看作是内部优化(比如减少南北流量)，但随着开发人员体验功能的增强，它们显得更重要。借助C2C网络功能，可以实现更复杂的应用程序到应用程序逻辑。这时候Cloud Foundry也开始拥抱更广泛的开源网络世界。卷服务扩展了可以在平台上托管的应用程序类型的范围，从而使操作人员可以为应用程序开发人员提供针对网络可寻址存储设备的文件系统挂载。

容器网络

回到网络世界，没错，容器到容器网络工作为开发人员增添了一大批宝贵的功能。它还代表Cloud Foundry社区从此开始在服务网格领域开发标准和项目的转折点。这项工作始于采用容器网络接口(CNI)，该规范方便基于容器的平台与底层网络层进行交互以简化配置。下一个阶段是2017年采用Envoy代理。最近，整个Cloud Foundry网络堆栈都将Istio + Envoy作为默认组件，以支持集群入站/出站和跨容器网络功能。

Kubernetes + Cloud Foundry

最近，Cloud Foundry社区欣然接受了另一个开源项目：Kubernetes。这始于捐赠Kubo，这是由Pivotal、谷歌和VMware共同开发的项目。Kubo迅速成了Cloud Foundry Container Runtime，而Elastic Runtime(更通俗的名称是传统的Cloud Foundry PaaS)被改名为Application Runtime。这使我们的社区充满信心，向采用Kubernetes作为底层的容器编排层迈出几步需要这种信心。

Eirini项目致力于让Cloud Foundry集群可以在架构中使用Kubernetes，并最终替换Diego代码库。

在过去这五年，社区创建了另外许多变更和扩展项目，很难逐一密切跟踪。一些项目已演变成大多数安装的Cloud Foundry系统的关键组件。另一些项目在完成使命后现已放到基金会的阁楼。

不变的是什么?

过去这五年没有变的两点值得强调一下：我们社区致力于提供世界一流的企业开发体验，以及社区致力于平台不断发展。这两个初心都不是“技术”，它们是社区的核心精神。我们一直努力将成千上万使用Cloud Foundry的组织和成千上万部署软件的开发人员吸引到该平台上。我们一直在学习如何更好地为企业开发人员提供服务，不断迭代和丰富这种体验。我们还不断完善架构，从更广阔的开源界提供的最佳技术中集众者所长。当然，我们仔细认真地进行这些更改。我们允许这种演变在频繁发布的同时逐渐引入新功能。

已发生了不小的变化，但不变的是Cloud Foundry社区致力于使我们的生态系统不断发展。

原文标题：From Bystander to CTO: My Five-Year Journey with the Cloud Foundry Foundation，作者：Chip Childers

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】