针对内部开发者平台的全面提案——平台工程++

作者：Giulio Roggero

在本文中，我将探讨平台工程，包括其在不同组织中的多样解释与实施方式。

我试图回答以下问题：“内部开发者平台是否仅限于自助式基础设施配置和应用部署？”

各组织对平台工程有着不同的处理方式：

• 一些组织构建基础设施自助服务工具，赋予开发者在基础设施管理上的自主权。
• 其他组织则专注于提升开发者体验，简化编码与部署流程。
• 还有一些采用市场中心化策略，创建容器、数据、API 等可重用组件的资源库。

尽管当前的平台工程实践有效简化了许多工作流程，但仍有些领域需要关注。数据、机器学习、API、安全、隐私等方面对于更好的软件产品生命周期至关重要。考虑这些团队是否能从现有平台工程实践中受益极为重要。

通过扩大关注点，超越单一层面，我们可以确保所有用户获得全面且增强的体验。

我认为，平台工程应涵盖端到端的价值链，以有效将产品和应用交付给最终用户。平台工程往往“仅仅”与基础设施简化和 DevOps 相关联，主要目标是为开发者提供自助服务平台。

如此构想，我们可能面临在平台工程师与开发者之间建立新隔阂的风险，类似于过去 IT 运维与开发者之间的障碍。此外，现在还需考虑数据、机器学习、API 等工程师。

在我看来，扩展平台工程及其工具，使其覆盖数字应用的整个范畴，对于通常所称平台的非典型方面也是一项值得努力的工作。

例如，我们可以将平台的组成部分视为：

• 多个团队可复用的设计系统；
• 库的仓库；
• 元数据目录；
• 团队工作协议；
• 确保合法合规要求的一系列护栏；
• 应用应遵循的一套标准。

我建议将这种扩展称为平台工程++。核心元素包括基础设施和 DevOps，加上数据/机器学习工程，以及软件组合性（API、事件、微前端、库及软件应用中可重用和进化的所有方面）。

我相信这将导致更全面有效的应用程序开发和管理方法。接下来的段落中，我将进一步阐述这一立场的理由。

平台导论，一个比喻

正如图书馆是人们共享书籍的地方，人们借阅书籍阅读，平台也是人们共享资源的场所。在数字领域，平台作为虚拟图书馆，使个人能够分享和访问各种资源。

可以将图书馆视为一个平台，其中资产以图书、视频、论文等形式提供。图书馆提供目录收藏、阅览室、咖啡厅等能力，人们借助研究助理、网站、订阅服务使用这些能力。图书管理员确保一切运行良好并井然有序，为私人群体、学校和其他团体提供自助服务体验。

图书馆用户不仅是读者，也可能是潜在的作者。他们可以从图书馆找到的其他书籍中汲取灵感、收集事实、构思论点，进而创作新的作品。

内部开发者平台

在这个类比中，我们可以将图书管理员比作平台工程师。他们的主要目标是确保平台用户享受顶级服务，并在与其互动时有愉快的体验。在比喻中，书籍可以类比为各种资源和工具（仅举几例）：

• 配备所需软件和配置的 Kubernetes 集群。
• 创建基础设施资源的 Crossplane CRD。
• 用于数据流的 Kafka 主题。
• 可供消费的数据产品。
• 设计用于正确格式记录日志（包括 traceId）的软件库。
• 用于在微前端中组合的 Web 组件库。
• 通过数字支付提供商发起支付的 API。
• 直接面向最终用户的完整应用。

图书馆的设施可以包括（仅举几例）：

• 列出所有可消费和可组合资源的服务目录。
• 创建新软件元素（基础设施、应用等）的自助服务 UI。
• 查看生产环境实时日志的命令行界面。
• 查看微服务指标的监控系统。
• 收集团队指标信息的一套评分卡。

这个我乐意称之为内部平台（或内部开发者平台，见下文）的图书馆，是所有技术魔法发生的地方。平台工程师管理这个平台，确保所有内部平台用户享有非凡体验。他们的方法是以产品为导向，专注于提供无缝且直观的用户体验。

根据平台用户的使用模式和组织的具体需求，平台工程师会微调平台以提供必要的服务。

平台是一个虚拟场所，资源（我将其称为项目作为同义词）被系统地排列和传播。通过优化时间利用，更多资源变得可获取。

通过有效利用这些项目（类比中的书籍），组织能够创造创新解决方案，优化运营，获得竞争优势。

在内部平台的能力中，能力提供者供应一系列基础资源（项目），包括基础设施、DevOps 工具链、SaaS 服务和工具，由平台工程师组织并持续策划。

每个能力构成平台的一个项目，具有：

• 定义：描述输入、输出、可配置行为、指标和文档；
• 生命周期：项目经历包括开发、测试、部署、运营和退役的生命周期；
• 消费与组合：项目可被消费并组合以创建更复杂的应用，成为其他可被消费的项目。

产品团队可通过用户界面、命令行和 API 与这些项目互动。AI 代理可以帮助团队简化使用，而项目则按照目录组织并附带相应文档。

合作的结果是新应用的诞生。这些应用随后可转化为原始资产，可被其他团队反复重用，增强了组织的开发者体验（DevX）。

这一循环可视作软件开发中的循环经济，资源不断被重用和重新利用，引领更高效和可持续的开发过程。

平台项目生命周期

平台项目种类繁多，但具备共同特点：

• 由纯文本文件描述（目前存在多种格式，期待未来形成统一标准）；
• 各项目间可建立关联关系；
• 拥有从创建、交付、运行到操作，再到编目以便产品与应用团队消费的生命周期。

值得注意的是，用户可以通过 UI、CLI，或是自动化任务的其他软件，乃至基于 LLM 的 AI 助手与系统交互。

若能访问包含应用运行所需所有行为描述与关系的综合内部平台，拥有一位 AI 伴侣协助将是多么有益。

想象一下，通过简单的对话即可完成查找项目、配置、发布以及在生产环境中运行和操作项目，这样的伴侣将极大地优化工作流程，提升整体效率。

我提议将此称为“对话式 DevX”，这将是我的下一篇博客主题。

内部开发者平台、平台之平台或内部平台？

尚不确定内部开发者平台应定义为多个平台的集成还是仅指其中一个平台。这是一个开放性讨论^[1]，欢迎各位交流见解。

名称固然重要，但本文不聚焦于此，而是内容本身，希望与tag-app-delivery^[2]团队共同探讨标准化命名法。

如开篇所述，平台工程不仅关乎基础设施，也不是 DevOps 的进化，而是旨在减轻创建、交付及运营应用、数据、API 和 ML 模型等软件项目人员的认知负担。

我观察到的趋势是，每种软件类型都有其对应的平台，但这些平台间的用户体验日益趋同，预示着所有软件平台可能汇聚为单一平台或“平台之平台”。

内部平台中的项目可分为多种类型：

• 基础设施资源：涵盖支撑应用与服务的基础软硬件，包括物理服务器、虚拟机、容器、云平台、数据库、ML 运行时等；
• DevOps 或开发者平台资源：定义与运行工具链的工具，以及运行时数据、API、事件、AI 模型的运维与观测工具；
• 数据、事件、API 资源：数据对许多组织至关重要，可来自多种源，结构化、非结构化或半结构化，静态或动态，受策略更新并产生事件；
• ML 与 AI 资源：机器学习模型能从数据中学习并做出预测，涉及定义、训练、部署与优化；
• 可组合资源：项目可被编排或编舞，根据类型采用不同模式，如 Saga 或微前端组合；可组合项目即用于组合的工具；
• DevX 资源：将 DevX 视作产品资源（内部市场与软件目录），内部平台的每一项都可作为他人宝贵资产。提供市场供项目创建、发布、维护、消费与评价，有助于形成软件循环经济；
• 团队协作资源：团队在内部平台中利用各类项目促进沟通与工作流程组织，包括问题跟踪、待办事项、文档等。理解平台本身对于有效协作至关重要。

内部平台可分解为多个子平台，获取诸如虚拟机、Kubernetes 即服务集群、函数即服务平台等“原始”运行时资源。

DevOps 工具对于资源与代码生命周期管理至关重要，与可观测性、安全性、身份管理服务共同构成基石。NoSQL 与 SQL 数据库、数据流和对象存储等数据存储常用于应用开发。

此外，LLM 模型经常作为服务通过 API 或嵌入运行时以增强团队创建的应用，而 Salesforce、Dynamics 365、SAP 等 SaaS 应用作为客户与产品信息的中枢，对云原生应用开发起关键作用。

所有能力均采用基础设施即代码方法管理，IaC 清单同样遵循代码、交付、运行、运维与团队协作组织的生命周期。

这种资源生命周期管理方式适用于不同类型的平台项目：开发者、基础设施、应用编排（API、事件、流程）、机器学习与数据。它们作为内部平台内的平台相互连接，可能共享数据库集群或安全策略等资源。

项目描述符以应用即代码（AaC）概念呈现：如同描述基础设施期望状态一样，描述组成云原生应用的所有平台项目的期望状态。

内部市场中定义了平台项目的可重用蓝图、可复用软件目录及各团队贡献的可作为其他团队构建模块的项目。得益于该市场，实现了平台可组合性策略。

内部平台提供 UI、CLI 接口，用户也可通过 API 编程方式交互。AI 作为伴侣，基于 IaC 和 AaC 清单提供上下文，简化平台用户的任务，包括资源发现、微服务与资源故障排查及新资源创建。

平台工程++是一种软件工程学科，以整体观聚焦于内部平台。

总结

采用平台工程++范式，相信平台工程倡议的投入产出比（ROI）将增长。因为平台成为业务应用的基石，消除了团队间的障碍，所有团队对构建其上的端到端应用有了统一视角。

目前先谈到这里，期待反馈！你怎么看？请在议题https://github.com/cncf/tag-app-delivery/issues/586留言，并有兴趣的话加入CNCF wg-platforms 工作组。旅程才刚刚开始！

参考文献

文中提及的“平台”特指“内部开发者平台”，或我更倾向于的“内部平台”，因这些平台不仅服务于开发者，还包括数据、ML、云等工程师。需区分内部平台与 Uber、Airbnb 或 Netflix 等业务平台。内部平台帮助企业构建与运营其业务平台，如 Spotify 创建 Backstage 作为内部开发者门户，并集成了更多工具来发展其内部平台以运作 Spotify 消费者平台。

请注意，已有论文涉及我将在博客中讨论的部分内容：

• CNCF 平台白皮书^[3]
• 平台术语表^[4]
• 平台工程成熟度模型^[5]
• 平台之平台倡议^[6]

希望本博客能为头脑风暴贡献力量。

感谢

这是一篇专为 CNCF TAG App Delivery 社区撰写的原创博客，希望你喜欢！

衷心感谢 CNCF TAG App Delivery 社区，为我们营造了一个开放包容的讨论空间。

特别感谢 Atulpriya Sharma、Lou Bichard、Tyler Pate、Abby Bangser、Stefan Daugaard Poulsen、Chris Plank、Marsh Gardiner、Rob White 和 David Stenglein 的深刻审阅。