16、跨平台应用自动化与平台采用指南

跨平台应用自动化与平台采用指南

1. API 边界分析

端到端应用自动化之旅结束后，我们的微前端示例及其依赖的数据库已正常运行。接下来探讨 XR/claim API 边界划分的原因。

端到端自动化分为四个阶段，可忽略第一阶段（准备 Crossplane 控制平面）。将其余阶段用四个 XR/claim API 分为三个阶段，原因如下：
| API 类型 | 原因 |
| ---- | ---- |
| 集群 XR/claim | 集群设置不仅与产品 A 相关，现代工作负载多部署在 Kubernetes 中，组织未来会有很多此类活动。构建单独 API 可实现复用和集中策略管理，且集群设置是一次性活动，对后续应用工作负载部署有跨领域影响。 |
| 入职 API | GitLab 项目入职的 XR/claim 作为单独 API 开发。无需为每个环境（生产、预发布、开发）都进行仓库和 CI 管道的入职操作，所以将 XGitProjectAPI/GitProject API 分开。 |
| 应用 API | 此步骤用于入职应用基础设施依赖和 CI 设置，每个环境只需进行一次。因此将 XWebApplication/WebApplication 作为单独 API。数据库供应有内部嵌套 API，将其分开是因为数据库供应有组织范围的策略。数据库 API 无 claim，仅作为嵌套 API 使用。 |

提示 ：入职 API 创建的仓库 URL 和访问令牌是应用 API 设置 CI 所必需的。入职 API 是一次性活动，应用 API 在每个环境中使用。若每个环境使用不同的 Crossplane，自动共享凭证可能有挑战。可考虑使用外部密钥库同步入职 API 的仓库详细信息，其他 Crossplane 环境可使用 External Secrets（https://external-secrets.io/v0.5.3/）同步这些 Secrets。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(集群 XR/claim):::process --> B(入职 API):::process
    B --> C(应用 API):::process
    C --> D(数据库嵌套 API):::process

2. 为何需要将基础设施平台作为产品

有三个关键原因需要平台团队开发 Crossplane API：
- 认知负载 ：组织会使用大量云资源和外部服务，配置这些资源和服务的属性多达数万条。若产品团队自行掌握这些知识，会专注于技术复杂性而非产品特性开发。需要专业团队将这种认知能力引入组织，将此工作抽象为平台团队管理的共享服务是合理的。
- 策略管理 ：基础设施和外部服务的使用策略来自安全、合规、产品和架构团队。需要集中团队在资源供应和使用时跟踪、整合和编码这些策略。若将资源自动化作为单个产品团队的一部分，很难保证策略的执行和更新。
- 复用投资回报 ：组织内许多工具、架构模式和基础设施设置模式相似，这些共性会转化为基础设施参考架构的复用。结合认知负载和策略管理优势，复用的投资回报经济优势明显。

3. 理解客户需求

基础设施平台团队意味着外部交付依赖，这是敏捷产品开发团队常避免的。产品团队常对平台团队提供的内容不满，存在交付时间线、积压耦合和合同薄弱等问题。平台团队应具备以下品质以满足产品团队的交付期望：
- 产品开发实践
- 快速启动 ：平台使用要快速简单。Crossplane 作为基于 API 的平台解决了部分问题，但还需提供快速启动指南、示例代码仓库、支持系统和详细 API 文档。将快速启动能力作为关键指标，通过产品和平台团队的持续反馈循环不断改进。
- 实践社区 ：建立包含平台和产品团队参与者的社区。产品团队的应用操作员可自然参与，他们能为平台 API 开发带来实际需求反馈。运行社区要有指标和激励措施，可用于共同创作、知识传递、双向反馈和加速采用。
- 可组合 API ：技术平台常限制创新，平台应具备一组细粒度的 XR，在此基础上可快速组合产品团队所需的 claim 配方。建议采用两层 API，第一层包含组织集中策略的细粒度 XR，第二层是配方层，包含产品级策略和需求。可有一组组织内复用的基本配方，同时为社区创新新配方留空间。部分组织设置可能需要 Goldilocks 治理，避免新配方过多。

• 自助服务 ：自助服务是构建平台的关键。类似云提供商，用户可通过控制台和 API 按权限管理资源。Crossplane 作为基于 API 的资源组合平台解决了部分问题，但要仔细定义产品团队将使用的 XR/claim API 的范围和粒度。这取决于组织规模、团队边界、开发人员/平台团队的技术成熟度等。首次定义完美边界较难，需通过测量自助服务指标迭代改进。除 API 边界，还需关注快速启动指南、技术支持系统和社区建设。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(快速启动):::process --> B(实践社区):::process
    B --> C(可组合 API):::process
    C --> D(自助服务):::process

• 协作式积压管理 ：单个集中的平台团队服务多个内部团队时，需管理积压工作以满足各方需求。可采取以下方法减轻风险：
  • 积压优先级排序 ：在优先级排序会议中，用时间关键性、错过机会和短期/长期商业价值等指标对每个积压项评分，并记录评分原因以提高透明度。所有有积压项的产品团队应积极参与，可使用评分滑块避免产品团队过度提高评分。
  • 期望管理 ：将产品团队视为最终客户，为他们设定何时能期望得到什么的预期。使用 Scrum of Scrums 或其他敏捷框架定期提供更新，包括进度和交付日期，对延迟交付保持开放透明。
  • 社区和治理 ：借鉴 Kubernetes 和 Crossplane 等开源项目的做法，通过建立强大社区提高交付速度。社区开发活动由核心贡献者组成的技术指导小组管理。产品团队的应用操作员可参与社区，有紧迫需求的产品团队可分配应用操作员共同创作产品。

4. 平台产品生命周期与团队交互

Crossplane API 开发可能经历多个阶段，每个阶段有不同的参与模式和开发者能力要求：
| 阶段 | 交互模式 | 开发者能力 | 特点与目标 |
| ---- | ---- | ---- | ---- |
| 概念验证和 alpha 阶段 | 协作 | 快速创新者 | 产品和平台团队密切合作，不要求 API 可扩展或可靠，旨在尽快实验可行性和价值。 |
| beta 阶段 | 从协作向自助服务过渡 | 快速创新者与能带来稳定性/可靠性的人员结合 | 继续协作工作，产品团队可通过自助服务门户请求访问新 API 并开始使用。平台团队与产品团队紧密合作完善自助服务门户和 API，目标是为组织使用做好准备。 |
| 通用可用性阶段 | 完全自助服务 | API 稳定可靠 | API 可供组织内任何人使用。 |
| 弃用和移除阶段 | 促进式交互 | 快速创新者 | 平台团队帮助产品团队摆脱对弃用 API 的使用。 |

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(概念验证和 alpha 阶段):::process --> B(beta 阶段):::process
    B --> C(通用可用性阶段):::process
    C --> D(弃用和移除阶段):::process

5. OAM 角色

OAM 规范提出了部署和管理云原生应用的三个角色：
- 应用开发者 ：专注于应用开发，全力开发直接为客户增加价值的功能。
- 应用操作员 ：减轻应用开发者在云原生生态系统中配置应用的复杂性，使应用开发团队能更快进行功能开发，间接为最终用户做出贡献。
- 基础设施操作员 ：减轻组织内配置云、其他基础设施和服务的复杂性，使应用操作员能专注于应用的配置和操作。

通过重叠 OAM 角色和本章所学的其他概念，可构建如下平台团队及其生态系统结构：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(组织 x):::process --> B(产品 1):::process
    A --> C(产品 2):::process
    B --> D(Scrum 团队 1):::process
    B --> E(Scrum 团队 2):::process
    C --> F(Scrum 团队 3):::process
    C --> G(Scrum 团队 4):::process
    D --> H(应用开发者):::process
    D --> I(应用操作员):::process
    D --> J(基础设施操作员):::process
    E --> H
    E --> I
    E --> J
    F --> H
    F --> I
    F --> J
    G --> H
    G --> I
    G --> J

这种结构展示了组织如何根据不同角色和团队分工，有效地进行云原生应用的开发、部署和管理，有助于提高开发效率、降低复杂性，并更好地满足客户需求。