平台工程或 API 治理，叫什么重要吗？绘制并标准化您的 API，以便在内部轻松访问和重复使用。
译自 Is Platform Engineering Really Just API Governance?，作者 Jennifer Riggins。
伦敦——“如果 API 治理 和 平台工程 有一个 Venn 图，它们将是一个圆圈，”Platformable 总监 Mark Boyd 在 4 月 10 日的 API 大会 主题演讲中争论道。
他不会区分你的 API 治理工具包和你的平台工程策略。也许你也不应该区分。毕竟，两者都优先考虑相同的理想客户画像：你的内部开发人员同事。
事实上，API 已成为开发人员希望访问和构建在任何内部开发人员门户和生产黄金路径之上的首选方式。而专注于 API 和数据标准化以及跨组织服务可重用性是任何平台策略的基础。
“API 是摇摆不定的狗，”Boyd 争论道，“因为 API 通常可以从根本上改变业务。”
他说，外部可用的 API 在业务周围创建了一个生态系统，开辟了新的市场途径。API 成为一种跨职能语言，允许技术和业务利益相关者进行交流。而且，他说，与不同业务部门构建 API 生态系统允许跨组织协作——例如通过内部开发人员平台——而不是培养内部团队和时间的竞争。
在每个人都试图用更少的资源做更多事情的时候，这一点尤其重要， 提高开发人员生产力 正是 开发人员倦怠 高发的时候。
那么，轻量级的 API 治理策略是什么样的？你如何克服 API 复杂性？APICon 受众问道。以下是如何立即简化这种复杂性。
API 生命周期如何开始？通常是孤立的。Boyd 反映说，API 用户需要一些东西，而解决方案架构师希望扩展现有 API 或更频繁地创建新 API。产品经理可能会参与其中，但仅在收集需求的开始阶段。
几乎没有检查已经存在的东西——可能是因为通常没有简单的方法来做到这一点。而且很少有围绕 API 的标准化来启动。
当被问及是否使用 OpenAPI、AsyncAPI 和 AWS RAM 等 API 规范格式时，只有大约一半的 APICon 受众举手。在整个组织中培养统一性并可能节省时间，因为至少此活动意味着以可理解且一致的格式编写了 API 的定义。
此外，只有少数受众表示他们创建或重用了数据对象模式：这意味着每个 API 都可能使用不同的数据模型来描述相同类型的事物。
Boyd 给出了用户帐户的示例：每个 API 可能会略微不同地创建用户帐户数据模型：一些可能使用 FirstName、LastName、title、organization 和 email，另一些可能为名字和姓氏创建一个字段名称，然后只要求提供电子邮件地址，而另一些可能还有更多字段。
Boyd 建议，在创建新 API 时应用 API 治理，首先规划开发人员的旅程。询问：痛点是什么？他们使用什么编程语言？他们依赖什么架构模式？
在开始时写下你的 API 的用例描述——不仅仅是 API 名称，他强调说。这种做法有助于 API 架构师阐明他们的 API 打算实现什么。然后可以在文档的开头包含此描述，这会增加可发现性，进而增加可重用性。而且，如果你计划对外公开你的 API 和文档，它会增加你的可读性和机器可读性。
“这种小用户故事模板有助于阻止开发人员[从]离开他们的流程并思考：好的，我应该使用哪个模型？”Boyd 说。
它还有助于组织内的 API 发现和可重用性。通过内部开发人员门户或 API 目录，所有内容都变得更容易搜索，因此更有可能找到和重用此 API，这比从头开始构建要便宜得多。
最后，当我们进入生成式 AI 开发人员生产力领域时，快速记下 API 的预期用途的练习也使其更具机器可读性，从而增加了 GenAI 编码助手建议它的可能性。这些步骤有助于减少对开发人员流程的干扰，并最终节省时间和金钱，因为开发人员专注于新的差异化工作。
为了帮助培养更多设计思维，Boyd 还建议撰写新闻稿，即使它可能永远不会被分享。
“想象一下这是项目的结束。您正在发布该 API 或 API 的新功能。您正在从外部对其进行描述，它将做什么？它将为他人创造什么价值？人们将如何使用它？”
他说，这种公共关系实践“将有助于澄清您对该 API 中所需的所有内容的思考”。
平台工程是一种社会技术实践，旨在通过创建共享服务的单一玻璃窗视图来降低来自不同工具的复杂性和认知负荷，从而更好地为内部开发人员服务。通过平台或内部开发人员门户进行 API 治理可以实现服务和 API 的可重用性，而不是让团队从头开始构建所有内容。
平台工程的一个关键支柱是制定黄金路径，Boyd 称之为“商定的架构”。这些通常是完成重复活动的最简单方法。通过明确这些铺设的路线，组织通常会看到复杂性和开发人员认知负荷的减少，这反过来又加快了向最终用户交付价值的速度。
由于康威定律至高无上，通信结构和技术本质上是相互关联的。Boyd 提供了另一个平台最爱，团队拓扑，这是一种工程管理系统，可以帮助组织团队围绕一种新的共享 API 治理方式。
引入团队拓扑方法 需要组织重组和将资源从业务流/线重新分配到一个集中平台团队，并赋予他们支持业务线团队在整个组织中使用通用工具的权力。
“通常，API 已进入业务线，每个业务线都有自己的 API 团队独立构建自己的 API，”Boyd 说。
科技行业的大部分正在缓慢地转向一个平台团队，该团队为团队拓扑称为流对齐团队提供集中服务。它不对这些团队强制执行 API 治理，而是平台即产品思维促使这些流对齐团队采用黄金路径，因为这更容易。您可能必须说服团队这确实是阻力最小的路径。
Boyd 警告说，团队可能会反驳，声称“我们的业务线非常独特且非常特殊”。并非每个团队都必须遵循您的黄金路径，但平台团队必须坚持其集中对整个或大多数业务线通用的资源的尝试。
这可能包括 API 目录和 API 管理解决方案。“甚至开发人员角色也可以由这种中央团队拥有，”Boyd 说，“因为这些开发人员角色可能匹配多个业务线。”
请记住从小处着手。他强调 API 文档和跨组织 API 可发现性的重要性，这是迈向最精简可行平台的第一步。因为根据 APICon 受众的反应来看，很少有平台团队拥有大预算，所以您必须利用现有资源。
Boyd 说，我们在科技行业中不断处于捆绑和解绑的状态。平台工程和团队拓扑的流行只是钟摆从开发人员自主权的近期极端值向重新捆绑通用服务的方向摆动。在尝试用更少的资源做更多事情的时候，这是明智的，但它也有助于解决工具过载和认知负荷问题。
Boyd 说，通常在 API 开发阶段，“我看到产品经理过早地从他们的职责中解脱出来”。然后，他们通常不会被带入，直到 API 准备好部署。
“我们需要在会议室里增加更多产品经理，”他对一群主要由 AI 架构师和 API 工程师组成的听众说道，其中只有一位 API 产品所有者。
他认为这是一个错误，尤其是在你的 API 目录和开发者平台需要“出售”给你的内部客户时。此外，由于在使用 OpenAPI 规范等内容时，你可以用人类可读的方式进行交流，从而让业务和技术人员更轻松地进行交流，因此没有必要将他们排除在外。
“你可以浏览它并讨论你公开的一些功能，然后仔细检查 [它] 是否符合他们最初帮助确定的那些功能性要求，”Boyd 建议道。
虽然该产品不会存在很长时间，但安全性通常不会在 API 创建结束之前引入，这不仅会影响代码安全性和稳定性，而且如果安全性无法清除，所有这些工作都将付诸东流。他说，如果 API 将对外公开任何数据或服务，那么尽早引入安全性尤为重要，“这样你就无需重新做出这些决策”。
他说，安全准则是解决早期安全性的绝佳方法。当他所在的数据和工具化初创公司 Platformable 团队与客户合作编写 OpenAPI 规范时，模型中公开的每条数据都会根据组织的数据敏感性、合规风险和品牌风险赋予一个风险因素——低、中或高。风险越高，你引入安全性的 API 开发生命周期就越早。
API 样式指南有助于推动可重用性的那种一致性，但它不是你需要从头开始创建的东西。API Stylebook 是面向 API 设计人员的一系列指南和资源。Boyd 称赞 Zalando 的 RESTful API 指南 和 Adidas API 设计指南 为典范。
由于 API 公开数据，因此 API 治理实际上也与数据治理有关，他认为。“我在很多企业中看到的是，API 治理和数据治理被视为完全不同的东西。”
由于 API 通常分散在各个组织中，因此 API 架构师可以通过创建商定的功能分类法来让数据团队的生活更轻松。这可能包括设置字段标准，例如尝试影响是否使用“用户”或“帐户”，以及是否在单个字段或单独的字段中使用“名、姓”。
他说，在转向 API 治理模型时，你不必返回并更新所有 API。但是，你可以在设计新 API 和更新旧 API 时遵循这些概述的步骤。
Boyd 说，遵循 API 架构影响者Mike Amundsen 关于 使用 EASE 规则指南实施 的建议，这有助于你评估是否要返回并重构现有旧技术以满足新的治理指南。EASE 规则考虑了四个可识别的品质：
- 有效性。API 是否按预期工作？
- 可用性。它是否以大多数用户希望的格式/语言提供？
- 可扩展性。API 是否可以在一天中的任何时间或任何流量负载下满足其用户需求？
- 效率。它是否在不花费大量精力、时间或复杂性的情况下满足所有用户需求？
“需要记住的一个关键点是，并非所有解决方案都需要在所有四个品质上都表现出色。如果 API 仅由单个团队在内部使用，那么它可能只具有最小的可扩展性和效率，”Amundsen 写道。“并且可能只需要一些额外的工作即可满足可用性需求。”
但是，如果要公开 API 或具有跨组织功能，则它需要在所有四个方面都得分很高，这意味着你正在引入的新 API 治理框架（例如样式指南）更有可能被采用。
API 蔓延是该行业十多年来一直在努力解决的问题，引发了巨大的可发现性问题。长期以来，孤立的团队一直在使用 API 作为连接内部和外部服务和数据的方式，同时使用内部和外部创建的 API。
没有哪个组织真正知道有多少 API 正在连接哪些服务以及公开哪些数据。这使得 API 标准化和安全性都更具挑战性。
幸运的是，Boyd 认为，该行业对 OpenAPI 规范 的大规模采用正在帮助解决 API 蔓延问题。OpenAPI 规范是一种用于描述 RESTful API 的机器可读格式。它允许开发人员和非技术人员轻松地理解和使用 API。
“有了内部目录，至少所有 API 都可以列在一个地方，以便人们可以查看。你实际上可以在内部开发者门户中拥有数据模型，以便人们[也可以]重用它们。”
他补充说，他的团队正在努力培养开发人员的反射，以便“每当你必须为你的 API 构建新内容时，你都应该思考，‘等等。让我查看内部目录，看看我们是否已经有了其中一个’数据模型或 API。”
Boyd 提到了四种不同的内部开发者门户工具：
- Backstage。他评论的 Spotify 开源内部开发者平台，目前需要产品经理来帮助维护“糟糕的混乱”文档和整体产品复杂性，例如需要向每条匹配 Backstage 的 YAML 实现要求的 API 说明中添加一行代码的额外步骤。
- Mia Platform。一种云原生平台构建器，帮助你构建并管理你的 IDP。
- ApiShare。一种 API 治理工具，用于追踪你生态系统中 API 的生产者和消费者。
- Port。Boyd 称之为“一款更易于用户使用的 Backstage，并带有慷慨的免费层级”的专有内部开发者门户。
他还建议将最近被 SmartBear 收购的 Stoplight 视为 API 设计工具。“我喜欢它的原因是，你可以在其中实际定义你的风格指南，”Boyd 说。“然后，当你构建你的 OpenAPI 规范时，它会告诉你是否超出了你自己的风格指南。”
如果你有外部 API 生态系统，你甚至可以公开发布你的风格指南。Stoplight 还维护 Spectral，一个开源linter，它可以根据你的风格指南、行业标准或更广泛接受的 API 设计最佳实践检查你的 API 设计。
他还建议通过 42crunch（一个 API 安全平台）运行你的所有 API，它可以获取 OpenAPI 描述并评估其稳健性。他还指出了执行类似评估的新开源工具，例如最近发布的开源 OWASP 规则集。
但是，正如他所说，巨大的 API 格局正在不断扩展——特别是如果你遵循Boyd 的 API 治理和平台工程重叠。迄今为止，它已收录了 2,159 个 API 工具。
无论你选择什么——无论你如何称呼这种服务和 API 标准化和可重用性策略——Boyd 都敦促你记住你的内部开发者是你的客户。你应该发布你的路线图并与他们分享，以获取反馈。这也支持内部采购，你可以在其中利用整个组织的开发人员的工作，这在这些更紧张的时期尤为重要。
当然，衡量你的计划结果。你可以跟踪的一些指标包括：
- 基础设施节省。这包括许可和运营支出。
- 质量。通过支持呼叫和事件的数量来衡量这一点。此外，Boyd 补充说，检查你的文档更新频率。
- 采用和使用率。Boyd 承认，当你无法始终知道 API 调用来自何处时，这可能特别具有挑战性。有时订阅数据可以提供帮助。你的文档被使用的频率是多少？
- 净推荐值 (NPS)。你的开发者推荐你的工具的可能性有多大？
- 编目的 API 数量。由于 API 蔓延，这将是一个持续的过程。
- 成本降低。包括客户获取成本和降低漏洞的成本降低。
“你的指标可能有所不同，”Boyd 强调，并指出这些想法中的许多想法是由 John Musser在他的工作中提出的 Ford的平台工程 计划。他的团队使用的一个关键指标是每个项目和整体节省的开发人员天数，计算为组织通过引入标准化方法节省的美元价值。
通过询问开发人员他们的痛点，并从那里制定你的策略，来启动任何 API 治理或平台工程计划。并跟踪数据，如四个黄金信号——延迟、流量、错误和饱和度。
当有疑问时，Boyd 说，创建一个理想的开发人员流程应该不断回答三个问题：
- 开发人员是否满意？
- 成本是否降低？
- 上市时间是否更快？
他表示，当你面对这种复杂性时，请记住：“你必须从小处着手，向你的团队和所有相关决策者展示好处。”