查看原文
其他

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

KubeVela 团队 阿里开发者 2023-03-08

阿里妹导读


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

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

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

云计算的发展使这些问题变得可以解决了。基础设施逐渐向云上迁移的过程中,催生了容器和 Kubernetes 的迅速流行,也为上述领域构建统一的标准,不同云厂商间 IaaS 的差异性被屏蔽,使用户在所有云环境中可以灵活使用资源,并且可以无缝的迁移和维护应用。
云原生的理念也因此得到快速普及。企业将越来越多的工作负载都迁移到 Kubernetes 之上,包括有状态或无状态的,比如微服务、大数据、AI、数据库、中间件等等。为了管理和运维这些应用,开发者不得不面对大量的底层 API,这形成了两个挑战。一方面,应用交付和管理标准的缺失,使各种工作负载都会形成自己的运维和管理平台,带来企业平台层的分化。另一方面,Kubernetes 对于业务开发者而言过于复杂,带来了很高的使用门槛和稳定性风险。
在 Kubernetes 和云原生技术对基础设施和工作负载层面的抽象逐渐统一的态势下,如何进一步简化和标准化应用交付与管理层面的操作和功能,成为接下来一个非常自然但重要的演化方向,也会成为市场真正需要角逐的战场。
2019 年阿里云与微软联合发布 OAM

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

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 的落地实践。

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

在最近 Gartner 发布的“2023 年十大重要技术趋势”中,“平台工程”(Platform Engineering)这一项和 KubeVela 的定位不谋而合。KubeVela 正在成为平台工程的最佳范式。记得一次社区例会上,社区的一位企业用户代表在分享他们的实践方案时说了这样一段话:“通过使用 KubeVela,目前在我们的团队,产品、后端、前端甚至是交付同事之间的沟通语言由原来的 Kubernetes 技术概念完全变更成了 OAM 的标准化概念,我们不再需要向具有不同技术背景的同事去解释技术,特别是 Kubernetes 复杂生态的技术。平台化、标准化理念正在公司生根发芽。”
云原生技术的普及催生了全新的应用开发方式,其带来的技术水位的持续上移,将会将应用的交付和管理带向成熟和统一。也许这条路还很长,但我们相信,在这场面向应用交付标准的冲锋中,KubeVela 的贡献势必会留下浓墨重彩的一笔。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存