## 基础设施管理的“巴别塔”困境最近，开发者 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）** 这些编程语言特性允许你定义一组行为（方法），然后让不同的类型去遵循（实现）它。只要它们遵循了相同的协议，你就可以用统一的方式与它们交互，而无需关心其内部具体实现。 ## 可能的出路：协议化基础设施如果将这个思路映射到基础设施领域，意味着我们需要的可能不是一个试图统一所有细节的“超级抽象层”，而是一个**标准的、声明式的“基础设施协议”**。 - **服务提供商** 可以发布其资源（如数据库、队列、函数）遵循的协议定义。 - **开发者** 则用与协议兼容的声明式代码来描述所需的基础设施状态。 - **工具或运行时** 负责将这份声明映射到具体提供商的实现上。这样做的好处是显而易见的： 1. **解耦与可移植性**：基础设施代码不再绑定到特定提供商的专有语法或工具链。 2. **生态竞争**：提供商可以通过更好地实现标准协议来竞争，而不是通过制造差异和锁定。 3. **工具创新**：围绕标准协议可以涌现出更专注、更高效的工具，而不是每个工具都试图成为“万能胶”。 ## 挑战与展望当然，从理念到落地充满挑战。这需要行业主要参与者（云巨头、开源社区、标准化组织）的协作，以定义一套足够通用又切实可行的核心协议。技术上的挑战包括处理不同提供商能力的差异、状态管理、以及性能与成本优化等。然而，Dax Raad 的推文引发的海量共鸣表明，**市场对解决方案的渴求是真实且迫切的**。当“基础设施即胶带”成为普遍感受时，或许正是重新思考基础范式的时候。与其在越来越厚的抽象层上叠加新的胶带，不如回到更根本的“语言”层面，尝试为基础设施的“巴别塔”找到一种通用的协议。这条路或许漫长，但可能是终结当前碎片化乱象，让开发者真正“管理”而非“拼凑”基础设施的唯一可持续路径。

Hacker News574个月前原文