AWS 的向后兼容性与 API 稳定性 - 永不废弃已发布 API 的方针所建立的信任
解析 AWS 坚持不废弃已发布 API 的实绩，与 Azure 的品牌变更和 GCP 的服务停用案例对比，阐述 API 稳定性对企业为何至关重要。
API 稳定性等同于基础设施稳定性
在云服务之上构建系统，意味着依赖该云的 API。API 一旦变更，其上构建的所有系统都会受到影响。API 的废弃或破坏性变更会迫使企业进行应用改造、重新测试和重新规划部署，意味着不可预见的成本和风险。AWS 自创立以来一直坚持不废弃已发布 API 的方针。2006 年发布的 S3 基本 API（PutObject、GetObject、DeleteObject）至今仍可正常运行。新功能以新的 API 端点或参数形式添加，现有 API 不做变更。即使 AWS 的服务已超过 200 项，这一方针依然一贯维持。
维护向后兼容性带来的实务价值
API 向后兼容性维护的实务价值虽容易被忽视，但极为重大。第一，降低现有系统的维护成本。API 不变更，运行中的系统就无需修改。「正常运行的系统不要动」这一运维铁律，由云服务商来保证。第二，保护长期投资。CloudFormation 模板、CDK 代码、Terraform 配置、CI/CD 流水线等云基础设施自动化投入的代码，不会因 API 变更而白费。第三，抑制技术债务。为追随 API 变更而进行的改造工作是一种不产生新价值的技术债务。AWS 的向后兼容性方针从结构上防止了这类债务的产生。第四，可按计划升级。即使添加了新 API 或功能，现有 API 仍继续运行，迁移时机可由企业自行决定。不会被服务商强制升级。
Azure 的品牌变更与 API 变迁
Azure 在 API 稳定性方面有着与 AWS 不同的历史。Azure 早期使用 Azure Service Management（ASM）API 体系，但 2014 年开始向 Azure Resource Manager（ARM）迁移，ASM 被逐步废弃。这次迁移要求重写现有脚本和工具，影响了大量用户。Azure 的品牌名称变更也很频繁。从 Windows Azure 改名为 Microsoft Azure（2014 年）、Azure Active Directory 改名为 Microsoft Entra ID（2023 年）、Azure DevOps 的前身 Visual Studio Team Services 的改名等，服务名和品牌的变更反复发生。品牌名变更虽不同于 API 的破坏性变更，但需要更新文档、培训资料和内部知识库，造成运维混乱。Azure 的 API 版本管理也较复杂。ARM API 以版本化形式提供，但旧版本可能设有支持期限，需要定期升级。
GCP 的服务停用历史
对 GCP API 稳定性的担忧根植于 Google 整体的「服务停用」历史。Google 在消费者服务中停用了 Google Reader（2013 年）、Google+（2019 年）、Stadia（2023 年）等众多服务。这种「不被使用的服务就停用」的文化也影响了 GCP。GCP 中，Cloud IoT Core 于 2023 年停用。使用 IoT Core 的客户被迫迁移到替代服务。Cloud Domains 也于 2024 年宣布停用。GCP 近年来为获得企业客户信任，明确了服务停用政策并设置了停用前通知期等改进措施。然而，「Google 会停用服务」的认知根深蒂固，成为企业决策者选择云平台时的顾虑。在 AWS 中，服务停用极为罕见。即使是使用量少的服务，只要有现有客户就会继续维护。这一方针短期内虽有成本，但长期构建了「选择 AWS 就不会突然失去服务」的信任。
维护向后兼容性的设计技巧
长期维护 API 的向后兼容性在技术上并非易事。AWS 能够实现这一点，背后有几项设计技巧。第一，API 设计阶段的审慎。通过 Working Backwards 流程，API 设计从客户用例反推进行。发布前经过充分讨论，降低了事后因「设计失误」而变更 API 的必要性。第二，以可扩展性为前提的设计。API 响应中添加新字段时，现有客户端可以忽略。新参数作为可选项添加并设置默认值。第三，版本管理策略。需要破坏性变更时，以新 API 版本提供，旧版本并行维护。客户可按自己的节奏迁移到新版本。这些技巧与 Two-Pizza Team 的自主性相结合发挥效果。各团队对自己服务的 API 承担完全责任，将向后兼容性的维护内化为团队的质量标准。 如需学习 API 设计最佳实践，相关书籍 (Amazon) 可作为参考。
总结
AWS 的向后兼容性方针从 2006 年的 S3 API 起已一贯维持超过 18 年，提供了降低现有系统维护成本、保护长期投资和抑制技术债务的实务价值。Azure 因 ASM 到 ARM 的迁移和频繁的品牌名变更，在 API 稳定性方面存在课题。GCP 受 Google「服务停用」文化影响，IoT Core 停用等案例损害了企业客户的信任。在云平台选型中，API 的稳定性和向后兼容性是应与功能丰富度同等甚至更加重视的要素。