基于 KubeVela 实践应用交付的平台工程新玩法 | 极客有约

如今，在 Kubernetes 上构建应用程序的开发人员，不仅要写代码还要负责交付和运维等。而 CNCF 云原生的 Landscape 已经有 1000+ 张卡片，覆盖应用定义与开发、编排与管理、运行时、配置、平台、可观测性与分析等，开发人员“认知负担”越来越重，所以企业需要从 2023 年开始更关注开发者体验，去聚焦开发者平台的相关建设，提供好用的工具集合或平台工程。

于是，InfoQ 发起了一场《极客有约》特别栏目《云原生趋势下的平台工程》。在本期节目中，我们邀请到了 KubeVela Maintainer & 阿里云技术专家曾庆国（悦达），以《基于 KubeVela 实践应用交付的平台工程新玩法》为主题，和大家一起聊聊传统意义上的运维岗位，未来会被平台替代掉？平台工程也会危及 DevOps 相关联的其它岗位吗？大公司是如何进行持续交付的？为什么阿里开发出 KubeVela 平台？

以下为访谈实录，完整视频参看：https://www.infoq.cn/video/Lwx1Xiq9CQb1qu3WpPqL

曾庆国（悦达）: 在我们进行 KubeVela 项目的过程中，有机会充分地与广大社区用户进行了交流和沟通，并吸收了各种企业的实践。在这个过程中，我们观察到大多数企业在进行高质量的持续交付方面存在一些共同的挑战。因此，我们想和大家分享一下，当我们去构建这种平台时，可能会遇到哪些挑战。

首先，我们认为最重要的一个挑战是，目前团队内，特别是业务研发、运维、测试和 QA 同学之间的合作边界变得越来越不清晰。过去，我们常常会说 DevOps 是由于开发和运维之间的割裂导致的问题。然而，云原生技术的发展正在驱动我们团队内各种合作，但这种合作的边界却变得越来越模糊。为什么会变得模糊呢？实际上，我们希望将各种 DevOps 技术和云原生概念推向前端，即业务研发侧，但这种推动如果工具、平台不完善，进一步导致了分工的不明确，可能会产生稳定性风险，这是我们无法容忍的。过去曾提出关注点分离的理念，即将团队内不同人关注的点或负责的点分离开来，关注点分离需要有一个明确的桥梁，以解决边界不清晰的问题。在后续的交流中，我们需要进一步细化如何实现这种分离。

第二个挑战是平台不可扩展性。在阿里内部，不同业务团队拥有不同的技术栈和业务场景差异，因此在应用管理环节缺乏一种标准的、共同认可的抽象模式。各个团队因此形成了自己的运维和管理平台，这导致资源效能和成本上的浪费。在开展 KubeVela 这样的项目时，我们一直关注其可扩展性，因为我们希望通过一个统一的标准或可扩展的体系去满足不同团队的需求。这些团队可能已经拥有各种各样的平台和复杂的需求，我们可以通过插件的方式来定制他们的需求。我们将在后续展开这个话题。

第三个挑战是在应用管理方面的配置不一致性。在不同环境中，我们的生产应用往往需要进行复杂的配置，但这些配置可能存储在不同的系统中。阿里曾经遇到过几次大规模故障，其中一个重要原因就是由于临时修改配置并没有进行统一的存储，导致了一系列的问题。因此，将应用管理中的配置存储、分发和管理整合到一个统一的地方是至关重要的。

第四个挑战涉及到不可度量性。在 DevOps 领域，高质量的持续交付需要明确的度量指标，用数据来体现整个 DevOps 是否执行得好。在大多数企业中，交付平台比较多，每个平台可能负责不同的垂直领域的需求，并可能堆积大量的功能来支持这些需求。但由于缺乏对整个 DevOps 链路数据指标的度量，我们无法充分利用交付过程中产生的数据。因此，交付过程的改进需要面临一些困难，包括如何提供正向反馈和数据支持。在考虑平台工程时，这是一个非常重要的环节。

第五个挑战是要考虑稳定性、性能和多集群可用性。对于规模较大的公司，日均应用交付数量可能会很大，因此交互控制平面的性能至关重要，不能出现宕机的情况。在资源层面、应用管理层面和用户使用层面，我们需要考虑如何应对多活、多地域、多集群和多规模等特性。

第六个挑战是平台离散性的问题。在完成 DevOps 过程时，业务团队经常需要切换到多个平台，这会形成一个 DevOps 领域的数据孤岛。我们已经看到了这些问题，并在内部进行了相应的体现。我们希望通过一种新的产品技术来帮助更多的企业解决这些问题。

曾庆国（悦达）：这个问题最近很多人关注。对于开发工具链的团队，他们通常无法直接为企业的业务价值做出贡献，而是被视为企业内部的一个消费组织。如果他们想要扩大自己的影响力，或者保持持续的投入，需要给业务线带来一些实际的价值。许多工具团队都试图向业务方向发展，他们希望打造出能够直接服务于业务的产品和平台，而不只是作为一些无关紧要的工具存在，比如使用可观测技术来帮助业务线提升价值。因此，平台团队不得不采用越来越多的平台开发形态，以解决这些实际问题。工程团队的投入取决于不同企业的现状，当企业业务不断发展，工程化问题不断凸显时，工程团队才会逐步被需要。同样当工程团队发展得越来越大时，其组织形式和工作模式需要被重新思考。这就是我们今天谈平台工程的前提。平台工程的提出就是为了让工程团队和业务团队间建立其健康的相互驱动力。

曾庆国（悦达）：这个问题上面已经做了比较系统地阐述，从各个维度进行分析。此外，像阿里、腾讯和字节这样的互联网企业具有一些独特性。由于这些企业的团队规模更大，团队成员的技术素质更高，以及业务规模更大，因此他们的实践更加前沿。因此，市场上出现的各种工程实践技术往往先源自这些企业，然后逐渐普及到其他企业中。在选择这些一线互联网企业的实践技术时，其他企业也需要进行一些自己的思考。

曾庆国（悦达）：在 KubeVela 研发和开源之前，业内有很多类似的工具或产品，能够解决一些关键的问题或挑战。其中一种产品像 Cloud Foundry，这是一个面向应用的平台，我们通常认为其为第一代开源的 PaaS 平台。另一个产品是 Heroku，也是一个类似的面向应用的平台。这两款产品在容器和云原生技术还没有普及的时候就已经应用了一些关键的容器和云原生技术。

这些产品的特点在于它们都能让业务开发者以比较便捷的方式将代码部署到云端。例如在 Heroku 直接将代码推送到云端的 CD 环节，对于开发者的整个成本是非常低的。这些平台也已经覆盖了常见的开发语言和框架，例如 Java、PHP、Python 等等，使得开发者更容易使用。这两个产品的区别是，Cloud Foundry 通常以开源的形式运作，更多用于企业的私有云。提到 HAL 库，这个产品主要应用于公有云中的一个场景，我认为这两款产品都非常创新，并且提出了很多新技术。在许多 Serverless 场景中，它们仍然在使用。例如，我之前提到的构建应用程序打包技术现在可能称为“镜像分层”，因为它将代码层和底层运行时分离。但是，像 Heroku 这样的产品在当前的社区中可能已经有些过时了，因为云原生技术在快速发展，而这两款产品的跟进速度或最终效果似乎很慢，迭代步伐已经放缓。我认为这两个产品开创了我们在 CD 领域开发者平台的先河。

另一类是容器平台模式，它是基于 Kubernetes API 形式封装的平台。这种平台的代表有一些典型的例子，比如 Rancher 和国内的 KubeSphere  等开源产品。这些平台的共同点在于，它们最初的目标是做好能力的仪表板，也就是通过 UI 管理 Kubernetes 资源。但是，对于业务开发人员来说， Kubernetes 下定义的各种概念仍然是一种高成本的开发方式。因此，除了做好仪表板之外，这些平台肯定还会在 DevOps 领域发力，以便更好地对接用户。

我们可以以 KubeSphere 为例，它是国内非常成功的一个容器开源产品。我多年前就开始关注它，因为它的 UI 风格以及管理风格都非常出色，遵循了 Kubernetes 的风格。它的产品模式是将云原生社区的常见技术，如 Service Mesh、可观测性和其他原子能力封装在一起，以平台构建者的形式提供整体解决方案。因此，这个产品非常适合我们构建容器云。过去，我在市场和社区中看到很多组织使用这种容器平台产品构建自己的容器云平台，这可以将他们从原来的 IaaS 平台升级到 PaaS 平台。虽然在国内有很多商业产品也是采用这种模式，但实际案例表明，这种产品难以推广到业务端，即不太适合大多数业务开发者。这是因为它的暴露形态仍然是资源或类似于 IaaS 的形式，对于业务开发者来说不够友好。

第三种模式的产品则是基于特定场景进行封装，例如基于 IaaS 或容器技术和企业的特定场景。它们的优点在于针对目标用户打磨体验，提升概念，让目标用户能够轻松使用。这种平台存在的问题就是可扩展性不足，也就是说它只能解决某一个问题或者说最小公共问题。当企业或者团队的需求越来越多的时候，这样的平台可能就需要采纳多个平台。在阿里或者其他团队内部，这种情况会导致不同的平台体验不一致，会拉低整个应用发布或者 DevOps 的效率。因此，在开始 KubeVela 之前，我们研究了不同阶段产品的优缺点，并且想要实践一款面向开发者的平台，以更好地解决平台团队和业务团队之间的耦合问题。

曾庆国（悦达）：我非常认同刚才的观点，即平台是经验的积累。这是非常关键的，因为做平台的人必须要有某个业务方向的经验，并且要有很好的经验延续。对于平台工程化，我更喜欢把它叫做平台工程化，因为它涉及到两个名词：平台 和 工程化。平台是指面向整个业务研发、交付和价值产生的开发者平台。对于 DevOps，虽然它提供了一些流程和工具，但我不认为它是平台，因为它没有让我们的经验可以很好地积累。因此，我们需要一个产品，即平台，来实现整个诉求的串联和经验的共享。这个平台需要有整体化的功能和易用的流程，以便 80% 的目标用户能够快速使用。

“工程化”是指将平台的原子组件进行封装，以适应不同企业和业务团队的诉求和能力。它是一个持续迭代的过程，需要标准化和更好的工程文化支持。平台工程化 是将平台进行持续迭代和升级的过程。

目前，平台工程化被认为是一个重要的技术趋势，因为它结合了业务微服务化和云原生化的趋势，成为业务架构的一个重要维度。由于微服务化，我们现在需要管理大量的服务，云原生化是相当于技术架构，技术架构就是把业务以更好的模式进行管理。然而，云原生技术的领域非常广泛，许多业务开发者甚至普通的平台开发者也无法清楚地理解它的全貌。由于需求和技术积累的复杂背景，对实践平台工程提出了更高的要求。另一个问题是业务开发者的需求，他们希望平台团队能够将能力附加到业务中，以提高业务研发效率和上线速度。但是，如何让业务开发者能够充分利用平台是一个高门槛的问题。容器原生化等新技术的出现也使技术生态持续演进，这可能导致平台开发者需要面对巨大的挑战。第三个方面是我们技术生态的持续演进，涌现出大量相关技术。这意味着即使我们去年成功上线了一个平台，但今年可能又会有新的技术标准出现，要求我们对平台进行改进。例如，像服务网格这样的技术架构从前年到去年再到今年，甚至明年都会进行较大的变更，这对于平台的构建者来说是一种巨大的挑战。我们不能每年都推倒重来，重新编写代码。因此，我们需要一种标准化的、趋于统一的技术演进形式，以便更好地接受新技术。

今天再来提一下平台工程的重要性，上述三个维度是重要的出发点。对于 DevOps，我认为它是一个整套实践的统称，而不是指特定的某一个技术。它的目标很明确，就是让业务的研发更加高效。像 ChatOps 这样通过一种聊天的介质实现整个自动化 Ops，以及 GitOps，它们都是在不同的时间阶段出现的实践方案，只是不同的方案而已。

不同的方案实践下来会得出不同的结果，就是它们更适合什么样的人群。我认为，只有那些不太成功的 DevOps 方案才会更适合 SRE，因为一般来说 Ops 方案都是由有 SRE 经验或很好经验的人、平台研发工程师等人去搭建或设计的，也就意味着设计出来的方案应该满足用户业务开发者的需求，而不是只满足自己的诉求。它们的目标是将一些重复的、或者对业务研发团队不熟悉的业务维度的工作，交给业务团队。如果某个方案只能更偏向于 SRE 团队或工程师，我认为这个方案可能不是 DevOps 中最好的实践方案。这是我的个人见解。

曾庆国（悦达）：我不确定今天的听众是否熟悉 GitOps 或使用过相关项目。在回答这个问题之前，让我们先来了解一下什么是 GitOps。在 GitOps 的概念出现之前，我们通常使用 Git 的 Webhook 机制或者其他流水线机制来推动自动化流程。GitOps 的核心在于自动化的运维操作。Git 是一种介质，而 GitOps 之所以以 Git 命名，是因为它充分利用了 Git 的几个核心要素。Git 通常用于存储代码，而与运维相关的代码也可以存储在 Git 中。

GitOps 和传统的 Git Webhook 或者流水线机制相比，在技术上有很大的不同。传统的 Git Webhook 模式通常是在仓库侧主动推送到某个平台，触发相应的流水线过程以执行自动化操作。而 GitOps 更多地是反过来的，即在 GitOps 平台这一侧，能够主动地观察到 Git 中的变更或相关制品的变更，并主动地进行相应的发布过程。这种 push 和 pull 技术实现的差异，主要是为了解决一些具体的问题，如安全问题和流水线管理等。同时，许多用户通常面临的是配置难度的问题。因此，对于团队成功实施 GitOps，需要注意以下关键点：

首先，相关应用或要交付的产物需要能够 IaC（Infrastructure as Code）或 IaD（Infrastructure as Data）。这两者的区别在于，IaC 是通过代码方式定义要交付的基础设施和服务应用等，而 IaD 则是使用完全固化的配置数据来描述这些差异，这两种模式都需要实施才能实现 GitOps。如果仍处于手动部署加包或外包的方式，还无法转换到 IaC 或 IaD 的方式，那么就无法进行 GitOps 转型。

第二个关键点就是 Review 的文化。在开源中，Review 是一个非常重要的环节。当我们编写代码或业务团队编写代码时，我们需要让团队内的其他成员进行一次或多次 Review。这个过程通过不同的人检查代码的正确性或最佳性来完成。同样，我们将部署过程通过代码来定义，那么就需要不同的人来检查这个过程是否正确，并且变更是否是允许的变更。在传统的审批流程中，审批人可能只能看到某个人在某个时间点发布某个应用程序的消息，但是很难知道这次发布具体意味着什么，他所做的更改是什么。而在 GitOps 中，因为已经实现了 IaC、 IaD，那么所有的变更都在配置变化中已经体现出来了。例如，我这次变更支持将镜像版本从 V1 更改为 V2，这个变更可能会有一些相关联的代码，也可能只是改变了一些环境配置，等等。通过 Review 的机制，让团队成员形成同步，确保审批人不仅知道他批准的是什么，而且知道这个变更背后所做的更改。

第三个关键点是 GitOps 的版本控制能力。当使用 Git 进行代码托管时，它具备天然的版本控制功能，每次变更都会被记录下来，这意味着我们随时可以回滚到之前的某个版本。在实践 GitOps 的过程中，企业或广义上的 GitOps 实践并不仅限于 Git 代码仓库，也可能使用其他的制品库，如 Docker 仓库、Helm | Chart 包等来存储发布阶段的制品或配置。因此，版本控制可以在许多制品库模式中实现。

最后一个关键点是 GitOps 的自动化过程。除了可能需要进行 Review 的机制之外，整个代码合并的过程都是完全自动化的。我们可以自动化地比对和同步差异，关键在于同步差异的过程中需要确定一个 source of truth，即哪个配置是准确的。在 GitOps 实施中，通常以代码仓库中的配置为准，以防止不同环境的配置漂移，这也是其核心所在。

在考虑是否可以实施 GitOps 时，每个团队都应该关注一些关键点，因为缺少这些点可能会影响到 GitOps 的优势体现。对于业务开发者来说，GitOps 是自动化的，提供了关键变更并能自动完成上线过程。在这个过程中，SRE 团队扮演着重要角色，他们需要维护 GitOps 的基础设施，并为不同的业务团队提供同步支持。对于 SRE 团队，重点是维持 GitOps 的安全、可靠性和可衡量性，需要打造支持平台和产品来优化这个过程。

曾庆国（悦达）：首先，我想澄清一个观点，即 KubeVela 与 GitOps 之间的关系。实际上，KubeVela 不是一个 GitOps 项目，这意味着使用 KubeVela 并不意味着必须使用 GitOps。相反，在社区中以 GitOps 而著名的项目有两个，分别是 Argo CD 和 Flux CD。这两个项目完全以 GitOps 的模式提供整个流程和相应的工具集和体验。在这个背景下，KubeVela 提供了一个解决方案，具体来说，在用户的应用模型方面，KubeVela 的核心定位是 Open Application Model（OAM），这是一个规范化的应用模型，以一种标准的应用模型帮助用户更好地完成应用交互。

关于 GitOps 这种模式，我们目前看到的用户主要来自国外。在国内，GitOps 的实践相对较少，但我稍后会提到并进行分析。在国外，像 Argo CD 和 Flux CD 这样的项目更多地基于原生 Kubernetes 资源描述，例如描述基础微服务或应用程序。这些项目需要学习 Kubernetes 的许多概念，例如 Deployment、Service、Ingress 等等，这些概念非常多。如果结合 KubeVela，它提供了一个简化的标准业务模型，业务开发人员可以根据其团队的情况选择需要理解的概念。例如，如果某个团队的容器化知识还没有普及，我们可以将模型和数据暴露给业务团队，基于 OI 模型，使其更加业务化。这些数据包括配置 jar 包地址或 gam 的一些参数等，这些是相对比较容易理解的业务配置数据。对于那些已经进行了容器化普及的团队，我们可以将镜像地址、环境变量和启动命令等参数暴露给他们。这里应用模型在这方面发挥了关键作用。我们在开源社区推广 GitOps 的整个体验也基于这一点。例如，我们结合了 Flux CD 的 GitOps 基础能力，其中包括自动发现变更、同步配置以及将其下放到集群等能力，与 KubeVela 提供的应用模型能力相互结合，形成一个完整的 GitOps 体验。我刚才提到在国外的用户更多地采用这种体验。然而，我认为在国内，落地 GitOps 需要满足许多前提条件，但大多数企业或项目团队无法满足这些条件，因此在国内的落地情况不是很理想。

曾庆国（悦达）：我认为差异非常大。首先，让我们简单聊一下 Backstage 项目的理解。当我最初看到这个项目时，它还处于早期阶段，是以开发者门户为出发点的。它的核心数据模型以企业 IT 资产的关联关系为基础。它的各种服务、API 和文档之间形成一系列关联，帮助开发者更好地理解它所管理的 IT 资产。随后，我们看到它基于完整可扩展性的框架，帮助社区开发者快速创建各种集成。因此，目前我们看到了一个非常良好的生态系统发展 。整个 Backstage 插件体系非常丰富，已经有上百种插件出现，这也是它在开源社区非常火爆的一个重要原因。在这种开源环境下，关键的创新点是将这种平台集成能力进行了开放，提供开发工具链，帮助社区开发者实现各种集成。

回顾过去，我们可以看到一些面向开发者集成平台的模式。最早期的模式是像 Confluence 和 Jira 这样的体系，这些体系围绕开发者的资料库、需求管理或软件工程相关流程管理。在这种开发者平台中，存在比较细节的分工，比如测试人员测试哪些功能、研发人员在哪些功能上进行开发，以及其他运维团队负责的任务。这种体验模式早期已经存在，现在也在不断发展。

在国内，出现了以代码和自我品牌为中心的开发者平台，比如阿里内部的 Aone、阿里云外部的云效、腾讯云的 Coding 和开源中国等相关产品。这些平台以开发者视角为出发点，围绕着代码管理、项目管理、需求设计、缺陷管理、测试管理和制品管理等核心特性构建。在这些平台中，代码和制品形式的流转更多地发生在不同的产品模块之间。每个产品内部都有非常丰富的功能机制，这种商业软件的玩法是开源平台无法做到的。这些平台对于企业来说采纳成本很高，包括商业软件采购成本、实践模式的落地成本以及企业自身需求匹配需要的自定义或二次开发成本等。

刚才提到云原生技术时，以容器、CI/CD 为基础的平台比之前提到的以代码和制品为中心平台模式可能会更简单一些。这几种平台模式中，DevOps 平台功能最为丰富，其功能集的体验因团队而异，有不同的效果。在国内，尚未看到以开源或生态建设的方式集成这类平台产品，但从技术上讲，我们可以探讨如何集成此类产品，无论是商业产品还是开源产品。

首先，我们需要解决的问题是在大型门户或平台内，如何整合子产品。在这里，一个非常核心的问题是业务模型，也就是我们核心的业务模型是什么？例如，像阿里的 Aone、云效等平台，其核心概念是制品，以制品横跨整个平台的相关子产品。另一种模式像 Backstage 平台中使用的 IT 间关系，所有的扩展都可以接入到这个关联关系网中。第三种模式则是以应用为核心，企业的核心 IT 资产都是应用，所有的服务都可以视为应用，甚至基础设施也可以看作应用。KubeVela 正是采用这种模式，将应用作为核心的业务模型进行整合。第二个问题是是需要建立一个统一的用户门户，其中必须考虑到统一的用户认证和权限控制。这可能需要单点登录以及 RBAC 等多种权限体系的实现，这是整合产品的一个关键点。第三个问题是体验，不同的子产品需要相互支持，如果它们之间是完全独立的，建立关联可能会很麻烦，这将增加用户的成本。因此，在集成时，建立更好的关联是至关重要的。最后一个问题是易用性，这是非常关键的。如果易用性缺失，那么即使整合了很多功能，也会对用户造成灾难。这几个点需要在考虑子产品集成时考虑到。

第二个关键点是如何避免架构的复杂性，因为这种集成型产品的架构很容易变得复杂。之前提到的例子在客户交付时需要花费很长时间和精力，因为它们的架构非常复杂，其中组件数量众多。因此，如何保持一个轻量级的架构，同时又能够实现良好的集成，是我们需要考虑的关键点。

第三个关键点是全链路的可观测性。作为一个数据驱动的平台，我们希望每次应用发布都能够产生各种数据，并利用这些数据来推动整个链路更加成熟和优化。因此，我们需要考虑全链路的可观测性。

最后一个关键点是数字资产的复用，它包含多种模式。例如，基于应用市场来复用开发的业务应用；基于 API 的模式来复用 API 管理；以及 AI 模型的管理等等，还有文档也是数字资产的一部分。如果我们能把这些东西都做好，就可以打造一个面向开发者的集成性产品。

对于 KubeVela 而言，我们在这方面进行了分层设计。在多个版本的迭代中，我们一开始考虑的是底层技术的集成。由于需要支撑平台团队的工作，我们选择了基于 Kubernetes 技术的生态链作为底层技术，并希望将围绕应用的工具链有效地集成起来，因此提出了应用模型的概念。应用模型的核心概念包括哪些？其中，组件是指不同的制品，可以定义成不同的组件交付模式，例如镜像或 ZIP 包等。运维能力被抽象为 trait 的概念，包含了运维领域的各种描述。工作流覆盖了到达应用终态所需经历的过程。策略用于定义交互过程中的一些规则。应用模型结合应用引擎技术，整合了云原生生态中的各种能力，并以统一的 API 接口暴露给上层平台。在第二阶段中，我们将开展一些集成案例，通过应用模型和统一的 API 接口将基本能力集成到实践中，如 GitOps 或 helm 包的交付可观测性等。这些实践基于一套扩展技术，以推动开源社区的发展。在这个过程中，KubeVela 的扩展框架展现了真正可落地的优势，这也促使着越来越多的社区用户开始基于该框架开展自己的扩展项目。这代表着第二个阶段，即该框架的成熟阶段。我们目前可以看到社区中有很多用户参与到这个过程中来。第三个阶段是在底层的技术 API 上实现了集成，但如何将这些信息传递给中台用户和开发者用户仍然是一个问题。

构建平台和集成平台是必要的，这涉及到 UI 交互、业务逻辑流程以及不同子能力的接入等问题。在这个环节上，类似于 Backstage，即在平台层面提供一套扩展框架，这个框架能够帮助开源社区的开发者围绕着应用 API 实现上层的交互。这个框架将应用作为核心，包括应用前生命周期和后生命周期，比如设计阶段、中间阶段的 coding、持续升级上线阶段等。在 ToB 领域，这个应用可以交付给多个客户。

KubeVela 在平台工程中提出了一个以应用为核心的概念，以及所有扩展点都是围绕着应用的。在底层 Kubernetes 维度，我们通过基于标准性 API 接入所有的 Kubernetes 技术，并通过一套可扩展的框架将可观测性的交互逻辑整合到一个平台中。同时，还需要处理用户认证权限以及不同产品之间的相互集成等问题，从而形成最终的综合性产品平台。KubeVela 平台致力于帮助我们的用户扩展整个平台实践，尤其是在以 CD 平台为主的业务领域。我们在这里强调的是 KubeVela 与 平台之间的关系，以及平台工程的本质。

曾庆国（悦达）：KubeVela 项目最初提出的形式是 OAM 模型，它引入了标准化应用的概念。现在，我们认为它的核心目标用户人群没有太大的改变，即支持企业平台团队构建自己的平台。当然，平台的理解在三年前和现在可能会有所不同，但是它的核心目标是一致的。我们的目标是支持这些平台团队更好地打造产品，并持续引入云原生的新技术。这是 KubeVela 的核心考虑点。

为什么会有这个出发点呢？因为在阿里内部和历史长河中，出现了许多平台，我们看到了这种差异。首先，我们希望通过一套核心的标准化应用规范来统一整个平台的工作流程，从而提高效率。在 KubeVela 的早期版本中，我们围绕 OAM 应用的渲染、分发等核心工作流程。在这个过程中，我们使用了多集群技术和工作流技术，这两个技术都是为了支持 OAM 模型应用，在面对复杂环境和交付需求时提供底层技术支持。

在去年的版本阶段（如 1.3、1.4、1.5），我们致力于优化和扩展底层技术框架，以适应不同的场景需求。我们还推出了一个 UX 的体系，这是为了证明我们的一套体系概念是可行、实现和落地的，以服务于开源社区用户。我们需要在实践中去验证这些理念，因此我们会开展一些标杆性实践案例，让更多用户直接使用。在这个过程中，我们影响了一批企业，比如招商银行和其他一些公司，他们认可了 OAM 的整个平台架构，并在他们的企业中进行实践和应用，同时向社区反馈他们的实践案例。

在 1.6 、 1.7 和 1.8 的版本阶段，我们进一步思考如何提高我们的扩展平台能力，即如何将平台能力提升到更高的层次。我最近跟一个互联网公司的团队聊天，他们负责支持多个业务线，但是在平台没有做好之前，他们必须承担一些运维的工作，同时还要开发平台和支撑业务线，这让他们非常痛苦。因此，我们需要将平台能力上移，以更好地支持不同的业务需求。因此，如果在开源方案中能够更加成熟地处理工具链和开发者工具链，使企业能够自定义自己的需求能力或平台功能时更加简单，同时在接入社区的已有能力时更加顺畅，这是整个项目成功的关键环节。

当然，我也注意到像 Backstage 这样面向开发者门户、以企业资源关系为主的模式与 KubeVela 存在本质差异。KubeVela 最初的原型是以 CD 为核心，推出了标准应用模型，现在我们将其提升到平台层面，不是要与 backstage 竞争，而是围绕应用这一核心概念在 CD 领域或 DevOps 领域打造整个平台集成，并尽可能地整合社区开放能力。因为应用模型是核心，单一的 API 有利于我们做各种各样的体验，同时不会增加太多负担。不同企业的实践可能会有所差异，但其根本模式是一致的。例如，百度、招商银行、京东等客户案例分享时，我们看到了它们的平台非常丰富，可能有些体验不一致，但核心的东西都是一样的，这就很好地实现了统一。通过应用这一介质，我们可以统一大家关于平台思路和核心要点的想法，这是一个非常关键的环节。

刚才提到为什么要加入这些端到端的案例，其实已经说明了，为了项目和产品的成熟。其他的开源项目也是同理，包括 Backstage，它不可能只做一套框架，不做具体的实践，这样是不可能成功的。用户可能不会采取这种方式。

我们也非常关注 KubeVela 会不会变得越来越重这个问题。我们希望插件生态越来越丰富，但是 KubeVela 的核心能力需要极度精简，非常轻量。这是我们的一个优势，可以快速部署一个基础的交互平台，占用资源很少，组件数量也很少。我们需要严格管理插件，并保持其质量。哪怕增加了一系列插件和 KubeVela 的核心，也不会让它变得过于沉重。插件的生态取决于不同企业的实践。

最后，对于 KubeVela 如何沉淀最佳实践，我们认为非常关键的是以行业为分割去沉淀实践案例，比如金融行业、新能源（理想汽车）以及钉钉等 ToB 企业。它们的实践从结果上看核心都是一样的，但是差异在于应用的不同制品。这意味着我们需要使用标准的应用引擎，然后通过插件化的形式来注入不同行业的特殊需求，比如流程管控等。虽然不同行业有不同的需求，但是我们的应用模型可以直接屏蔽掉这些差异，以满足不同企业的实践需要。在开发者层面，他们无法感受到这些底层差异的存在，因为前置的参数环节都是一样的，而最终的运行时类型选择是由平台团队来决定的。因此，包括灰度发布和分批发布等不同的需求都取决于不同底层插件的实现。但是对于最终用户来说，他们的体验是完全一致的。这就是沉淀最佳实践的方式之一。我们将最好的插件组合和解决方案与不同的行业进行区分，以便最终沉淀出具体的好方案。

曾庆国（悦达）：作为一名云原生开发多年的从业者，我深刻地认识到云原生技术对传统开发模式的颠覆。虽然对于自己，这种感觉可能并不是很深刻，但是当我观察其他团队或企业时，这种颠覆感就变得非常明显。

总结一下几个方面。首先，云原生技术对开发者产生了很多新的要求。例如，我们经常听到“左移”的概念，这意味着将一些运维工作转移到开发者身上，类似 XasCode，“代码即基础设施”和可观测、安全等。

以云原生为例，云原生应用的开发需要满足“12 要素”的规范。这些规范涵盖了从代码编写、服务依赖管理、配置模式、构建发布、运行管理等多个方面，包括了端口并发、日志记录等维度。这些规范指导着开发人员如何开发和管理云原生应用。

对于传统的团队来说，实践这些规范可能很复杂，因为传统开发只需要编写一些 Java 代码即可，而不需要考虑这些复杂的规范。这里存在一定的差距，许多企业会通过平台来解决这个问题。然而，这也带来了一个问题，就是把这些认知差异转嫁到了平台上。这是面向传统团队的一个非常大的挑战。

此外，随着技术的发展，不仅是运维团队，QA 和测试团队的工作重心也在发生变化。在阿里云等一些公司，传统的运维团队可能已经消失了，只留下了安全和 QA 团队。这些团队的主要任务是识别和解决业务线上的安全问题，并提出方案以进一步提高质量，并将这些方案沉淀到产品或平台中。因此，这种类似于阿里团队的变化，逐步在一些创业团队、中小企业以及一线互联网公司中出现，都在“左移”，朝着业务侧面的变化方向发展。然而，这些变化可能对许多传统开发者来说仍然具有一定难度。我不能说传统的开发模式不好，因为许多企业仍然坚持着这种模式。是否需要进行转型取决于业务需求、规模、场景和行业的特殊要求等因素，而团队的综合能力水平也需要适应新技术体系的要求。此外，市场上的技术人才状况也会影响我们的开发模式。因此，我认为平台化的颠覆性变化是相当大的。

曾庆国（悦达）：我认为平台的本质是一个工具，它的核心作用是提高参与人的效率。在这个平台体系中，有不同的参与方。其中，平台工程师和 SRE 团队负责落地和研发所谓的平台。很多组织可能由原来的运维团队或 SRE 团队升级而来的平台团队。这些人的责任和目标有所改变，目的是用更好的平台来支撑其他参与方。业务团队的研发工程师负责业务研发，因此他们是平台的核心用户。平台的目的是帮助这些工程师提高效率。

除了业务团队和平台工程师外，还有安全团队、质量团队、测试团队和产品团队等。安全团队主要负责洞察业务的安全隐患并提出安全生产的相关解决方案。质量团队和测试团队负责提供产品测试方关的工具链或相关的平台解决方案。产品团队则负责业务产品的设计和对整个业务结构的负责，因此也是平台的一个使用方。如果平台发展得越来越好，参与的各方都将有明确的责任和业务价值。平台团队需要持续演进来不断满足各方的需求。

平台成为各个团队之间分工的纽带，各自确定好自己负责的范围，以及各个团队价值衡量的规则。对于不同规模的企业，需要基于实际情况进行配比划分。总之，平台的发展将为团队带来明确的责任和业务价值，并需要持续不断地演进以满足各方的需求。

曾庆国（悦达）：我对这个问题的理解是，目前的运维团队主要的职责是确保业务的稳定性和质量，解决故障并保证业务能够正常运行。在理想状态下，如果故障能够被业务发现并快速定位和解决，那么运维团队可能就不需要存在了。但是目前来看，大多数团队仍然需要运维人员来维护业务的稳定性和质量。

曾庆国（悦达）：我们之前已经提到，这是所有平台团队都在思考的问题。现在平台团队都希望通过提供自身的能力来帮助业务团队，使业务能够更快地得到支持。这些能力包括可观测性，例如运行情况、内存占用和分布情况等。但如果能够将发布效率、效能和业务级别的指标直接反馈到业务团队，将会对整个业务的高效迭代产生关键的影响。

另外，运维人员的人力投入也是一个问题。通过打造平台，运维人员的投入可以减少，他们也可以转移到平台开发方面，实现进一步的晋升。在某些企业或团队中，这种做法也有一定的影响力。

根本的问题还是要在业务中产生价值。我们不能只做一些重复性的工作，而是要在业务的演变过程中承担创造性的部分责任。这是一个核心的要点。

曾庆国（悦达）：KubeVela 在中小企业场景中的实践和应用价值非常好。事实上，我认为在一些中小团队中，甚至更容易实践平台的这种实践。为什么这么说呢？因为刚组建的团队可能缺乏完善的人员组成，例如在原有的模式下，组建研发团队需要考虑招聘研发人员、测试人员、运维人员和产品设计人员等。但现在，市场上的人才越来越贵，许多新团队或中小团队可能只能招聘业务研发人员，而其他人员可能缺失。因此，我们看到许多团队缺少运维人员，只有研发人员，这些人希望平台能够帮助他们解决重复性的问题。

我认为不仅大公司能够实践好平台，一些中小团队也能够做得很好。只是工具的选择可能不那么复杂，一些中小团队的需求可能非常简单，他们只需要一个 Serverless 平台，上传代码或制品，帮助他们安全稳定地发布业务即可。虽然需求不同，但我认为平台需求都是存在的。目前来看，KubeVela 项目有一半的社区用户是中小用户，他们使用平台以解决一些急需的问题，甚至不需要扩展，只需要社区提供的核心引擎和基础扩展能力就足够了。

曾庆国（悦达）：尽管 KubeVela 目前的插件技术体系和产品体验已经为容器化场景提供了广泛的支持，但对于非容器化场景的支持相对较少。然而，KubeVela 的应用模型的设计是不绑定容器技术的，基于虚拟机部署应用程序的传统形态，它是能够支持这种场景。

例如，像招商银行这样的金融机构需要同时在虚拟机和容器化场景中部署应用程序。在 KubeVela 的平台层封装之后，KubeVela 的组件层可以帮助屏蔽掉这一层的差异，从而使用户在使用时感知较少。此外，对于应用程序状态观测和相关管理操作的发布，KubeVela 也可以实现相对一致的支持。

此外，对于云服务的其他部分，例如在使用云资源时可能需要使用 PaaS 服务、数据库、网关服务或存储服务等，KubeVela 通过其生态系统中的核心组件基于 Terraform 技术，将云资源链接到 KubeVela 的应用程序模型中，从而基本上可以覆盖所有的公有云云产品，并通过 OAM 应用程序模式来进行交付。观众可以参考相关社区的文档来了解更多细节。

杨振涛：我们今天关于平台工程的话题就聊到这里了，欢迎大家关注，非常感谢悦达老师的分享。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！