平台即产品，需通过“访问、推广、新增能力”三项测试。高效平台强调组合优于抽象，封装流程与配置，并解耦交付。目标是民主化构建，提供持久价值。
译自：Three Core Principles for Sustainable Platform Design
作者：Abby Bangser
平台即产品将平台工程的范围从狭窄的技术解决方案扩展开来。平台要求组织转变交付价值的方式。一个高效的平台通过以可扩展和可持续的方式提供高度情境化的工具，为软件团队节省更多时间用于专注于收入的工作。
以技术为中心的平台设计通常只解决了更广泛挑战的一部分。要充分实现平台的承诺，组织不仅要考虑技术组件，还要考虑如何封装提供和消费反映组织标准和约束的托管服务的体验。
评估平台设计时要应用的测试
应用产品思维可以明确，平台不应试图解决所有用例，也不应强制采用单一的狭窄路径。相反，平台产品是一组精选的解决方案，它们编码了业务独有但又在应用程序团队中足够通用、值得分享的内容。
评估平台价值的一个实用方法是测试它能多好地支持三个基本结果：
- 平台消费者在需要时访问所需内容需要多长时间？ 平台必须支持对服务和资源的按需访问。当开发者面临大量的交接、长时间的等待和其他摩擦时，他们最终会浪费大量时间和精力，或者最终求助于影子IT。
- 在全组织范围内推广一项平台能力变更需要多少人、多少时间？ 中央负责人应该能够通过单一操作升级和控制每个实例。如果缺乏这一点，环境就会漂移，维护工作量会变得难以管理。
- 向平台添加新能力需要多少人、多少时间？ 可持续的平台架构允许专家贡献自己的能力。平台团队独自无法维护CI、数据、AI或网络等领域的所有服务。专家必须能够及时发布通过前三个测试的能力。平台团队的作用是使这种贡献模式成为可能。
支撑高效平台的技术原则
平台设计中一个常见的错误是过于依赖当前的 инфраструктура 和配置工具。这些工具虽然有用，但不足以管理复杂的过渡、多样化的系统以及组织自身的流程。
以下三个原则反复构建了能够通过价值测试并随着时间推移适应不断变化的需求的平台。
组合优于简单抽象
抽象很重要，因为它为开发者提供了一个单一的接口，隐藏了底层工具的细节。当这些抽象以API的形式提供时，它们将用户体验与实现解耦。开发者无需关心某个能力是用Ansible、Terraform还是主机脚本实现的。
一旦存在一致的API抽象，组合就成为可能。组合允许能力创建者依赖他人发布的API并重用它们，而无需成为每个领域的专家。如果没有组合，平台要么重复工作，要么过于激进地集中化，从而减慢了组织向最终客户交付价值的能力。
流程和配置的封装
在平台工程中选择“构建”，考虑到构建、购买或混合的选择，是昂贵的。这意味着你只应投资于构建组织独有且对许多团队都有价值的东西。使公司独一无二的不仅是自定义的基础设施、配置和策略，还有任何相关的流程。
Crossplane、Terraform/OpenTofu、Open Policy Agent (OPA) 和 Kyverno 等声明式语言在基础设施、配置和策略管理方面取得了进步。然而，命令式操作仍然很常见，尤其是在云提供商CLI、内部系统或缺乏合适声明式接口的环境中。而且这些语言都不包含诸如管理较长工作流、离线活动和手动步骤（如审批）等作为核心需求的流程。
平台必须将基础设施、配置、策略和流程封装成一个连贯的单元。没有这一点，你就无法安全地组合服务或将它们作为构建块依赖。这是因为任何非平凡服务的行为都跨越多个无法同步协调的工具。
有人说，组织创建流程是其过去痛苦的“疤痕组织”。这使得任何流程对组织而言都特别独特，并且难以改变和现代化。未能考虑到需要整合这些业务关键需求的系统最终会增加比它们消除的更多的复杂性。
平台是您的组织中唯一一个您应该充分认识到支持符合业务要求的解决方案意味着什么的场所。
针对每个环境优化的解耦交付
软件中的架构选择在集中编排和分布式编排之间摇摆。平台两者兼而有之，因为它们既需要控制能力的提供时间和方式，也需要跨多个集群和非Kubernetes位置进行扩展。
集中式规划提供控制。分布式交付实现规模化。平台应在中央编排器中定义规则和执行，然后依靠分布式部署引擎在正确的位置和形式交付能力。这避免了紧耦合编排的限制，并减少了规模化带来的运营负担。
将原则付诸实践
虽然这些原则可以通过多种架构实现，但Kubernetes已成为构建平台的默认控制平面。许多云原生项目已经出现，旨在创建支持大规模平台的Kubernetes原生架构。
自定义资源定义 (CRD) 背后的组合
有几种工具可以帮助在Kubernetes内部管理基础设施。Crossplane和云提供商操作符已经展示了声明式协调如何解决早期基础设施即代码 (IaC) 方法难以解决的漂移和规模挑战。
随着Kubernetes资源的增多，组合它们的需求也随之增长。Helm和Kustomize等打包工具提供了帮助，基于控制器的解决方案进一步扩展了这一点。Crossplane v2 Compositions、kro ResourceGroupDefinitions 和 Kratix Compound Promises 都将一组Kubernetes资源聚集在一个单一的CRD后面。这为开发者形成了一个清晰的抽象。
通过自定义控制器管理业务关键需求
封装为能力创建者提供了一种在配置、策略和流程上进行单一且可验证变更的方式。声明式工具解决了大部分配置挑战。但企业平台还必须支持命令式逻辑，因为存在遗留系统、合规步骤和复杂工作流。有意的打包可以暴露一个稳定的API，编码工作流逻辑并输出一个可部署单元，供下游系统管理。
Kubebuilder和Crossplane Providers等控制器框架基于低级的controller runtime工具构建，这些工具允许开发者在操作符内部嵌入命令式逻辑。Kratix Promises通过通常更简单易用的Open Container Initiative (OCI) 兼容容器接口实现了相同的目标。
作为解耦交付模型的两层GitOps
很少有真正的能力只使用一个集群进行部署。平台需要协调跨集群、云提供商和SaaS系统的部署。KCP和Karmada等工具帮助将资源调度到多个控制平面。Kratix使用两层GitOps模型将声明式工作负载路由到正确的目标。
成就解锁：平台构建的民主化
一个基于这些原则构建的、以Kubernetes为中心的架构可以满足按需API、情境感知解决方案和舰队管理资源的测试。然而，平台的持续性要求我们还需考虑维护平台服务目录的成本。这触及了第三个平台测试的核心：向平台添加新能力需要多少人、多少时间？
如果所有新增功能都必须通过一个中心化团队，无论是由于他们是唯一拥有权限的人，还是因为他们是唯一拥有扩展平台技能的人，那么平台的增长就不可持续。虽然大多数人都能看到中心化团队是唯一被允许贡献的问题，但更大的风险是第二个障碍：人们没有意识到由于贡献的挑战，他们正在创建隐性障碍。
如果贡献者需要理解过多的操作符框架、工作流引擎或领域特定语言，平台就会变得更难扩展和减速——这通常需要一个单一的中心化团队来交付所有新的平台能力，并参与更新和扩展现有能力，即使架构允许独立的插件。
一个符合组合性、封装性和解耦交付的连贯打包模型，允许专家专注于编码他们的专业知识，而不是专注于与生态系统其他部分的连接。例如，Kratix Promises将逻辑封装为OCI兼容容器，可以在定义能力时使用任何语言编写，从而降低了专家的门槛。
平台的三项简单质量测试可以揭示对平台设计的更深层次需求，即让贡献安全便捷，从而解锁规模并支持长期可持续性。
提供持久价值而非短期修补
当团队可以按需访问所需内容，当中央负责人无需手动处理每个环境就能指导行为，并且当专家无需学习大量工具就能扩展平台时，整个系统就会变得更易于运行和演进。
强大的平台能为工程师节省时间，减少运营阻力，并将组织复杂性转化为你可以自信管理而非恐惧的对象。一个基于这些原则构建的平台不仅能清除今天的障碍。它还为整个组织的规模化、安全变更和稳定贡献创造了条件。
