一个接口，所有协议：开发者如何应对基础设施碎片化难题
基础设施管理的“巴别塔”困境
最近，开发者 Dax Raad 在社交媒体上的一条吐槽引发了广泛共鸣：“我不知道人们现在是怎么管理基础设施的。每个服务都有自己的专属 CLI/配置文件，而且它们对 Terraform 的支持越来越差。你的系统从来不会只用一个提供商，所以大家是不是就把一堆这些东西胡乱拼凑在一起？” 这条推文在一天内获得了超过五万次浏览，评论区迅速被各种解决方案和无奈吐槽淹没。
从 SST、Pulumi、Ansible 等工具，到“就待在 AWS 上别动”、“用 Python 脚本调 REST API”、“这是工作保障”，乃至“今天的基础设施就是披着仪表盘外衣的胶带”——所有人都认出了这个问题，但给出的答案大多是“工具”，而非“根基”。
抽象层的局限与“锁死”的根源
问题的起点往往是熟悉的：你在一个云提供商上构建，然后他们调整定价、弃用某个 API，或者你发现它不再适合，但迁移过程异常痛苦。难点不在于概念本身，而在于每个提供商都说着一套不同的“语言”。
最直接的思路似乎是“抽象”——在上面再建一层。这正是 Terraform 以及众多其他工具尝试过的路径。然而，抽象层并没有真正解决问题，它只是转移了问题。你依然依赖别人来跟进每个提供商的更新，依然在等待插件被开发出来，依然可能因为一次许可协议变更而回到原点。
正如开发者 @Zenul_Abidin 指出的：“抽象正在失效。当提供商可预测时，Terraform 是有效的，但现在每个服务都在推出自己固执己见的层。” @aalachimo 则将其与商业动机联系起来：“提供商们减少对 Terraform 的支持，更多地说明了他们在为‘锁定’优化，而非基础设施在进化。”
从编程语言中寻找灵感
@jetpen 触及了更结构性的问题：“在基础设施和平台提供商之间，对于如何配置任何东西都没有兼容性，因此不可能有一个单一的实现在 GCP、AWS、Azure、OCI 等平台上都能工作。” 他说得对，确实没有兼容性。但根本原因或许可以换个角度理解：缺乏一种标准化的方式让服务来描述自身。
这时，一个关键的思路转变出现了：这其实是一个在软件内部已经解决了的问题。
- Swift 有协议（Protocols）
- Go 有接口（Interfaces）
- Rust 有特质（Traits）
这些编程语言特性允许你定义一组行为（方法），然后让不同的类型去遵循（实现）它。只要它们遵循了相同的协议，你就可以用统一的方式与它们交互，而无需关心其内部具体实现。
可能的出路：协议化基础设施
如果将这个思路映射到基础设施领域，意味着我们需要的可能不是一个试图统一所有细节的“超级抽象层”，而是一个标准的、声明式的“基础设施协议”。
- 服务提供商 可以发布其资源（如数据库、队列、函数）遵循的协议定义。
- 开发者 则用与协议兼容的声明式代码来描述所需的基础设施状态。
- 工具或运行时 负责将这份声明映射到具体提供商的实现上。
这样做的好处是显而易见的：
- 解耦与可移植性：基础设施代码不再绑定到特定提供商的专有语法或工具链。
- 生态竞争：提供商可以通过更好地实现标准协议来竞争，而不是通过制造差异和锁定。
- 工具创新：围绕标准协议可以涌现出更专注、更高效的工具，而不是每个工具都试图成为“万能胶”。
挑战与展望
当然，从理念到落地充满挑战。这需要行业主要参与者（云巨头、开源社区、标准化组织）的协作，以定义一套足够通用又切实可行的核心协议。技术上的挑战包括处理不同提供商能力的差异、状态管理、以及性能与成本优化等。
然而，Dax Raad 的推文引发的海量共鸣表明，市场对解决方案的渴求是真实且迫切的。当“基础设施即胶带”成为普遍感受时，或许正是重新思考基础范式的时候。与其在越来越厚的抽象层上叠加新的胶带，不如回到更根本的“语言”层面，尝试为基础设施的“巴别塔”找到一种通用的协议。这条路或许漫长，但可能是终结当前碎片化乱象，让开发者真正“管理”而非“拼凑”基础设施的唯一可持续路径。
