一场向应用交付标准的“冲锋”

作者 | KubeVela 创始团队

在 InfoQ “2022 中国技术力量年度榜单”中，KubeVela 获得了 “十大开源新锐项目” 和 “开发者最喜爱的十大开源项目” 双料大奖。这个开源至今仅两年多的云原生开源项目，为什么得到这么多开发者的认可？它因何而来，又将到何处去？就让我们跟随 KubeVela 创始团队，一起了解它的开源故事。

1 云原生下的开源标准化演进

回顾过去信息产业几十年的发展历史，整个行业存量的数千万台服务器，在集群管理、资源切分供给、资源调度、任务编排、应用交付、应用运维等领域，一直没有形成标准和规范。几年前一份行业调研显示，全球服务器平均资源利用率不超过 10%，这里面存在巨大的社会资源浪费，也存在巨大的优化空间。

云计算的发展使这些问题变得可以解决了。基础设施逐渐向云上迁移的过程中，催生了容器和 Kubernetes 的迅速流行，也为上述领域构建统一的标准，不同云厂商间 IaaS 的差异性被屏蔽，使用户在所有云环境中可以灵活使用资源，并且可以无缝的迁移和维护应用。

云原生的理念也因此得到快速普及。企业将越来越多的工作负载都迁移到 Kubernetes 之上，包括有状态或无状态的，比如微服务、大数据、AI、数据库、中间件等等。为了管理和运维这些应用，开发者不得不面对大量的底层 API，这形成了两个挑战。一方面，应用交付和管理标准的缺失，使各种工作负载都会形成自己的运维和管理平台，带来企业平台层的分化。另一方面，Kubernetes 对于业务开发者而言过于复杂，带来了很高的使用门槛和稳定性风险。

在 Kubernetes 和云原生技术对基础设施和工作负载层面的抽象逐渐统一的态势下，如何进一步简化和标准化应用交付与管理层面的操作和功能，成为接下来一个非常自然但重要的演化方向，也会成为市场真正需要角逐的战场。

2019 年阿里云与微软联合发布 OAM

2018年前后，阿里云云原生团队和微软同时看到了这个方向，在一次于阿里硅谷中心的深度交流和头脑风暴后，双方当即决定联合起来，共同孵化这个应用交付与管理体系，并于 2019 年联合发布了应用标准化模型 OAM（OpenApplicationModel），为云原生生态的应用平台建设提供理论依据。

2 KubeVela：一场向应用交付标准的冲锋

OAM 的开源引发了业界不小的震动，不少企业都在进行积极的推广验证，这其中当然包括阿里的多个产品线。然而一段时间之后，阿里云云原生团队意识到要真正解决用户的问题，只靠模型还远远不够。由于没有具体的实现方案，仅遵循 OAM 模型的思想，仍会使系统之间形成巨大差异，特别是在规模较大的场景下。比如阿里内部就形成了多套实现，能力无法复用，应用间也不能互通。而在社区的推进过程中，得到的更多反馈是 OAM 模型没有实现，很难落地使用。因此云原生团队下决心要把 OAM 的实现做出来，并且是以开源的方式去做，这也是来自社区的呼声。

KubeVela 开源团队在沟通技术实现细节

KubeVela 就此诞生。

新技术要解决原有问题，而不是带来新的问题

KubeVela 诞生于 OAM 社区，也是第一个将“以应用为中心”的设计理念落地的项目。发展到 2021 年 5 月，阿里云联合信通院发布业内首个以 OAM 为核心的“云计算开放架构”标准，将 OAM“模型”化虚为实，也对 KubeVela 后来的发展起到关键作用，推动其成为一个真正意义上的跨云应用交付与管理平台。

2021 年阿里云与信通院联合发布开放应用架构标准

凭借过去做云产品的经验积累，KubeVela 团队深知一个新技术想要顺利推广，很重要的一点是在解决原有问题的同时，尽可能降低用户采纳的成本。社区对之前的实践和功能做了充分兼容。当 KubeVela 发布第一个正式版本的时候，用户做的操作更像是升级而不是使用一个全新的系统。为了保证社区后续的演进不偏离这个路线，在设计之初 KubeVela 创始团队就定下了一些核心原则，指导整个 KubeVela 开源社区的长期发展。

（1）兼顾用户友好和可扩展性

KubeVela 基于 OAM 模型提供用户友好的上层抽象，但这些抽象可以随时扩展以满足用户的各种需求。这就避免了 KubeVela 项目成为了一个只能解决“最小公分母”问题的“鸡肋”项目。这是一个非常重要的创新。

（2）可编程

而在众多的可扩展性设计中，KubeVela 最终选择了 Infra as Code 的可编程扩展方式。因为这种扩展方式不仅简单易用，还可以方便的模块化和插件化。这个选择不仅提供了扩展 KubeVela 的最佳方案，还为后来的插件市场等生态能力打下了基础。

（3）以工作流为核心的交付模型

在 KubeVela 被开源社区逐步采用的过程中，根据大量的用户反馈和调研显示，看似非常碎片化和复杂的各类应用交付与管理场景，其背后确实是有一个非常本质的基础模型存在的。这个基础模型就是“工作流”，所以在 KubeVela 创立后，团队很快就开始同时演进 OAM 模型本身，引入了“工作流”这个基础模型并且在 KubeVela 实现了一个非常轻量级的工作流引擎。而“工作流”这个特性本身就又与 Kubernetes 和 GitOps 生态天然互补，所以这个关键创新很快就成为了 KubeVela 被大量采用的”杀手锏“。

（4）以业界最广泛和最真实的场景作为项目演进指南针

KubeVela 的发展过程中，大量关键的设计比如对交付 Helm 组件的完善支持、基于 GitOps 的核心交付流程、以多集群 / 多云 / 混合云环境作为首要交付目标等，都是结合阿里内部大规模实践，同大量的开源社区用户一起打磨、设计、然后最终实现出来的。这也是为什么很多人评价 KubeVela 是一个非常接地气的项目。这种基于阿里最佳实践但又紧贴业界最广泛场景的演进方式，对于 KubeVela 项目的广泛采用，做出了至关重要的贡献。

云原生时代的工具和技术百花齐放，对于企业来说，如何将这些丰富的技术快速落地为我所用，是一个很大的挑战。KubeVela 的价值就在这里。如果做一个类比的话，它有点像云原生生态的 “Spring 框架”。在 Java 生态中，开发者可以通过 Spring 快速构建业务应用，使用一致的编程模型、不需要了解各类技术框架的细节，从而能够大幅降低技术门槛。相对应的，KubeVela 是将云原生技术组件和企业应用连接起来，建立管理和运维交付的标准，让开发者对云原生的关注点从 Kubernetes 向应用平台升级。

更多的功能和更低的门槛，怎么选？

OAM 先进的理念、社区的用户基础加之阿里内部大规模的实践检验，使 KubeVela 初期的发展非常顺利，正式发布的第一周就冲上了 GitHub 的 Go 语言项目的趋势榜榜首。

同时，它也不可避免地遇到了刚起步的开源项目都可能遇到的问题。

首先，开源项目要成功的一大关键就是用户初始体验，而早期团队一般会更注重产品能力研发。KubeVela 本身的灵活性和可扩展性强大，这就导致第一个用例要么过于简单无法突出特色，要么过于复杂跑不起来。为了解决这些问题，团队开始重视安装复杂度、第一个用例的设计、文档结构的设计等等。直到现在，社区也一直在不断完善相关工具和文档，让初始用户可以低门槛体验项目。

第二，可扩展性是 KubeVela 与生俱来的核心设计。但开始的时候，KubeVela 的扩展点众多，但是没有一个统一的概念，没有对应的工具链，因此，几乎没有社区开发者能够知道如何进行扩展。因此社区提出 Addon 的产品概念，将扩展能力以相对规范的形式进行开发、整合。投入开发者重点维护全链路工具，打通 Addon 的开发、存储、分发、升级机制。目前 Addon 的产品概念已成为 KubeVela 的特色之一。

第三，随着项目面临的场景越来越多、功能越来越丰富，KubeVela 不可避免地会遇到复杂性挑战。2021 年下半年，KubeVela 迎来 v1.1 版本，加入多集群管理的能力，同时也具备了通过工作流驱动整个交付过程的能力，这些都大大提升了 KubeVela 整个项目的可扩展性，但是也加剧了用户使用的门槛。也是在这时，KubeVela 团队意识到，项目的用户群体需要分层：下层是 PaaS 的构建者和运维，基于 KubeVela 的引擎能力去构建 PaaS，他们需要充分的灵活性和扩展性去适配企业内的不同场景；而上层是业务的开发者，相对来说他们更需要一个简单易用的平台，快速满足业务开发需求。于是，社区开启了一个新的项目 VelaUX, 以插件化的方式集成到 KubeVela 内核上，使用户可以通过点击一个插件实现安装一个直接开箱即用的平台。VelaUX 的出现也将 KubeVela 从以 Kubernetes 为主的技术性高扩展性项目实现向平台化高扩展性项目的跃迁。

热爱，就是一种竞争力

相比于那些已经在公司内孵化好再开源的项目，KubeVela 是特殊的。它从第一天起就在社区发起、社区演进，甚至 KubeVela 这个名字也是由早期成员投票产生的。KubeVela 的初创团队邀请了许多 OAM 早期采纳公司的工程师一起来合作开发，保证项目核心部分的代码质量和稳定性。剩下的许多模块设计也都是在社区群策群力下完成的，比如官网的 UI 设计、命令行功能的使用方法、对于云资源支持的优先级等等，确保 KubeVela 许多用户体验方面的设计都建立在满足社区最广泛需求的基础之上，也保证了 KubeVela 项目贴近开发者的初心。

KubeVela 发展初期，团队成员每天打开 Github 页面都能看到大家给出的使用反馈、建议、以及代码贡献，这给了初创团队很深的感触和鼓舞。工程师在贡献开源的时候，其实都是在做自己喜欢的事情。如果一个人一直在做自己喜欢的事情，这本身就是一种强大的竞争力。KubeVela 社区也通过构建包容、开放、专业的协作环境，鼓励大家参与到开源建设中来，肯定每个人的工作，尊重每个人的价值。

从诞生之初， KubeVela 就是按照面向全球的开源项目去运作的。为使社区保持持续的生命力，2021 年 7 月，阿里云将 KubeVela 捐赠给 CNCF ，渐渐将影响力渗透到北美、日本、西班牙、英国等多个国家。如今，KubeVela 贡献者已经遍布全球，所在的企业和组织超过 70 个。不久前，KubeVela 正式晋升为 CNCF Incubation 项目，证明项目的影响力和成熟度得到业界认可。

KubeVela 社区的贡献者们

今天，企业对 KubeVela 的采纳程度正在快速提升。在阿里云内部，KubeVela 已经陆续成为 SAE、ACK One、EDAS、云效、CDN 等多款产品的 PaaS 内核；在社区中，招商银行、第四范式、中国电子、Napptive 等大量国内外公司也正在企业的平台工程中展开 KubeVela 的落地实践。

3 让平台化、标准化的理念生根发芽

在最近 Gartner 发布的“2023 年十大重要技术趋势”中，“平台工程”（Platform Engineering）这一项和 KubeVela 的定位不谋而合。KubeVela 正在成为平台工程的最佳范式。记得一次社区例会上，社区的一位企业用户代表在分享他们的实践方案时说了这样一段话：“通过使用 KubeVela，目前在我们的团队，产品、后端、前端甚至是交付同事之间的沟通语言由原来的 Kubernetes 技术概念完全变更成了 OAM 的标准化概念，我们不再需要向具有不同技术背景的同事去解释技术，特别是 Kubernetes 复杂生态的技术。平台化、标准化理念正在公司生根发芽。”

云原生技术的普及催生了全新的应用开发方式，其带来的技术水位的持续上移，将会将应用的交付和管理带向成熟和统一。也许这条路还很长，但我们相信，在这场面向应用交付标准的冲锋中，KubeVela 的贡献势必会留下浓墨重彩的一笔。

开源意味着不问责，我们准备好应对比 Log4Shell 更大的安全危机了吗？｜Log4j 一周年特别报道

阿里过去一年裁员达19000人；字节跳动布局中国版 ChatGPT；马斯克称下周将开源推特算法代码｜ Q资讯

技术裁员正在助长新的创业潮：本来犹豫要不要创业，没想到公司替我做了决定

活动预告

你也被火爆全网的 ChatGPT 惊艳到了吗？你也在思索下一代“人机交互”的理想形态是怎么样的吗？机会来了！这一次，让我们相约 3 月 11 日北京线下，看专业学者分享研究成果，听技术大佬畅谈实践经验。探讨智能对话新方向，展望人机交互新未来。OGeek 小布沙龙与您不见不散！更多详情可扫描下方二维码或阅读原文了解更多。

继续阅读

阅读原文

关键词

云原生

阿里云

技术

能力

企业