云原生平台为构建和部署软件设定了标准。它们使十二年前还不存在的企业能够在竞争激烈的市场上取得成功。开源云应用平台Cloud Foundry(CF)一直是这一成功的驱动力,使企业能够更快地构建、测试、部署和扩展软件。
确保云原生技术得到高效和安全使用是一场持续不断的战斗。这使得Kubernetes作为在软件开发和生产中快速部署和管理容器化应用程序的一种方式而兴起,并引发了对CF未来的疑问。
VMware在2021年1月关闭了其完全托管的CF Pivotal Web Services(PWS),这是否意味着Kubernetes“赢了”?这是否意味着CF的“终结”?
CF会消失吗?不会,因为CF的核心是平台和开发人员之间的协议,而且这种体验的需求量仍然很大。CF打包、调度和运行开发人员的应用程序,前提是他们遵守12-factor应用程序方法论。这种方法涵盖了从代码库和依赖关系到日志和管理流程的所有内容。它确保了平台顶部的应用程序层可以在云环境中扩展和壮大。至少,它提供了一个统一的应用程序架构,可以跨多种编程语言工作。
该协议认为,云原生应用程序可以通过标准化方法以可预测和可靠的方式运行。12-factor方法的其他优点在一些规则中有说明:
——“如果12-factor应用程序无法完成其工作,则会崩溃(或正常退出)”
——“12-factor应用程序不依赖于任何系统工具的隐含存在。”
这些规则所创建的属性使得Kubernetes如此流行,比如并发性、可处置性和模块化,但这并不奇怪,因为Kubernetes也是一个云原生平台,并且遵循与CF相同的规则。
CF的未来在于改变并寻求利用Kubernetes。正如RedMonk分析师Stephen O'Grady去年评论的那样,Cloud Foundry的未来是如何“提供Kubernetes之上和周围的抽象,以改善开发人员和运维人员的总体体验”。
CF与其说是一个单一的平台,不如说是一个契约。现在有几个系统存在于不同的开发阶段,遵循CF的平台开发者协议。
第一种是“传统的”CF,基于VM的Cloud Foundry。这是由BOSH在VMs上部署的,BOSH是一个虚拟机编排器,用于在许多不同云提供商的VMs上部署、扩展和维护应用程序。
第二个是KubeCF,它为Kubernetes容器化BOSH版本。这个官方的Cloud Foundry基金会项目允许使用其他CF团队使用的同一个BOSH版本,同时为流行的容器编排器提供最稳定、最忠实的CF实现。
还有另一个官方的CF项目cf-for-k8s,其重点放在Kubernetes上。这个项目采用了Kubernetes原生方法,涉及到对实现和架构的巨大改变。这个项目处于早期的测试阶段,并会推出Open Container Images(而不是BOSH发布)。此外,由于Kubernetes有一个容器运行时,CF的Diego被删除,gorouter被Istio和Envoy替换。
由于cf-for-k8s项目对CF组件进行了更改,cf项目团队必须维护的代码大大减少。我们还预计,随着KubeCF依赖的工件停止发布,KubeCF将逐渐采用cf-for-k8s的生产可用组件。
最后一种选择由谷歌开发,它被称为kf,是Kubernetes的cf工具的客户端重新实现。谷歌将其视为一种迁移工具,使用户可以从部署源代码到CF,直接到GKE之上的GCP Kubernetes集群,但它已经支持许多最常用的命令和标志。这是一种专注于谷歌产品的专有方法。不过,在Kubernetes集群上使用一个简单的shell别名部署和管理应用程序的想法很有吸引力。
还有更多的创新发生在CF和Kubernetes的优势都得到充分利用的地方,我们非常希望CF on Kubernetes意味着中型公司(而不仅仅是大型企业)将受益于CF提供的业务优势和体验。
此外,了解CF持续的业务价值也是至关重要的。
CF提供的用户体验是运维人员的最爱
从开发人员和运维人员的角度来看,这些好处很吸引人。Cloud Foundry位于基础设施(IaaS)层之上,提供基础设施服务的抽象,并通过单个平台简化操作。CF使用其CF推送体验部署应用程序,运维人员喜欢这种体验,因为他们不必担心服务发现或应用程序部署在何处等问题。
CF是开源的,可以降低许可成本
当考虑更快的上市方式时,开源CF(OCF)可以显著降低IT成本。由于开源软件是免费使用的,它降低了与商业应用实例的昂贵许可证费用相关的成本。对于使用“CF-as-a-Service”云计算选项的组织来说,这也是一个抛弃过多基础设施占用和取消七位数支持合同的机会。OCF通常需要一个更大的运维团队来支持对OCF的代码贡献,但最终还是会节省大量的成本。
CF通过自动化为大型组织提供适应性
CF还向大型组织提供了CI/CD和DevOps的灵活性。尽管CF可以将一个应用程序快速投入生产,但它使一家金融服务公司能够在不到7天的时间内修补ZombieLoad攻击。这个项目也在不影响应用程序团队或正在运行的应用程序的情况下完成。
CF坚持的设计降低了复杂性,但仍然允许定制
CF消除了运维人员的复杂性和痛苦,但它所做的假设和优化并不妨碍其可配置性和可扩展性。它的可扩展性不允许CF的性质发生变化,但是允许精确的定制。例如,我们开发了一个“BOSH Splitter”工具,这意味着客户可以将他们的维护任务(如调度stemcell(VM-image)轮换)分散在多天和小窗口中,而不是一个2天的部署。
CF从一开始就采用了“多云原生”设计,避免了供应商锁定
CF被设计成一个开放平台出现的时候,没有多少企业考虑多云,CF可以很好地应对当前的供应商锁定问题。作为一个开放平台,CF抽象计算资源,以创建跨不同云提供商部署服务和应用程序的标准方法。对于使用CF并采用混合和多云方法的企业,CF的抽象帮助他们拿到更好的服务合同。
CF为敏捷应用程序迁移奠定基础
虽然CF是结构化的,但对于那些考虑云原生的公司来说,一旦基础工作完成,CF就可以实现有效的应用程序转换。根据我们自己的经验,我们为一家农业生物技术企业迁移了1132个非生产和生产应用程序,并不需要开发团队的关注。这个项目涉及到修复所有清单和271个Java管道,并且在不停止工作流的情况下实现。
在一个需要加速变革的商业世界中,Cloud Foundry正在不断发展,并响应软件构建、测试、部署和扩展周期的需求。这不仅意味着更快地进入市场,也意味着保持开发反馈周期的重要性。它不仅具有可预测性和可靠性,而且具有可扩展性。它在规模上易于使用,还是一个经济高效的解决方案。Cloud Foundry的设计是为了抽象复杂性,因此它知道如何在你没有注意到变化的情况下改变。