周一早会，运维负责人老张把一封邮件投到了会议室的大屏上。IBM 发来的 Terraform Enterprise 续费通知，价格比去年涨了 40%。会议室安静了三秒，然后炸了锅。
“我早说了，HashiCorp 换 BSL 那天就该跑。”后端 Lead 李明第一个开口。
“跑去哪？HCL 写了三年，几百个 module，你说迁就迁？”老张反问。
“OpenTofu 不是一行代码都不用改吗？”
“那 Terraform Cloud 的 state 管理、policy 检查呢？换了 OpenTofu 这些谁来做？”
这场对话，2026 年正在无数团队里重复上演。IBM 完成对 HashiCorp 的 64 亿美元收购已经一年，Terraform 的商业策略走向还在观望期，但账单已经先到了。摆在桌上的选项从来没有像今天这么多，也从来没有像今天这么让人纠结。
最直接的逃生舱：OpenTofu
如果你的痛点纯粹是许可证和定价，OpenTofu 是阻力最小的路径。
这个由 Linux Foundation 主导的 Terraform fork，2024 年 1 月发布 GA，到 2026 年已经是 CNCF Incubating 项目。它的承诺很简单：100% 兼容现有 Terraform 代码，永远开源。你把 terraform 命令换成 tofu，.tf 文件一个字都不用改，state 文件直接读取。对于那些有几百个 module、几十条 pipeline 的团队来说，这种零摩擦迁移几乎是唯一现实的短期方案。
但 OpenTofu 解决的是”谁拥有这个工具”的问题，不是”这个工具够不够好”的问题。HCL 的表达力天花板还在那里，provider 生态虽然共享但发展速度开始分化，社区贡献者的精力在两个项目间拉扯。选 OpenTofu 的团队通常是这样想的：先把许可证风险卸掉，其他的以后再说。
实际操作中，很多公司的 CI/CD 管道里硬编码了 terraform 二进制路径、版本锁定、provider mirror 地址。迁移看似只是换个命令，实际上要逐个排查每条 pipeline 的依赖。如果你用了 Terraform Cloud 的 remote execution，还需要自建或者购买替代的远程执行环境。这些隐性成本不写在官方迁移文档里，但会实实在在地消耗团队两到三周的时间。
用代码思维重新定义基础设施：Pulumi
李明后来私下跟我说，他真正想推的其实是 Pulumi。
“你见过用 for 循环批量创建 VPC 的 HCL 吗？那个 count 和 for_each 写出来的东西，三个月后自己都看不懂。”他打开 VS Code，展示了一段 TypeScript 写的基础设施代码。函数、类型推断、条件逻辑、单元测试，和写业务代码一模一样。
Pulumi 从 2019 年就开始押注这条路线：用 TypeScript、Python、Go、C# 这些真实的编程语言来描述基础设施。到 2026 年，它最大的差异化变成了 AI 集成。Pulumi AI 可以根据自然语言描述生成基础设施代码，Pulumi Insights 用 AI 分析你的云资源拓扑并给出优化建议。对于本身就是软件工程师的团队来说，这消除了”学一门 DSL”的认知成本。
代价是什么？生态覆盖和团队分裂。Terraform 的 provider 覆盖了几乎所有云服务和 SaaS，Pulumi 虽然能桥接 Terraform provider，但原生 provider 的数量和成熟度仍有差距。如果你的栈里有冷门的云服务或者内部系统，可能会撞墙。更微妙的问题在于团队内部：运维出身的人习惯声明式思维，开发出身的人偏好命令式逻辑，Pulumi 天然对后者更友好，这可能在团队里制造出新的技能鸿沟。
管控层的争夺：Spacelift 和 env0
老张关心的问题其实不是用什么语言写 IaC，而是谁来管理执行流程。Terraform Cloud 干的事情——远程 state、plan 审批、policy 检查、drift 检测、成本预估——这些在 OpenTofu 裸奔模式下全都没有。
这正是 Spacelift 和 env0 切入的位置。它们本质上是 IaC 的编排和管控平台，不绑定具体的 IaC 引擎。
Spacelift 的卖点是 policy-as-code 做得极其细致，用 Open Policy Agent 写规则，可以精确到”这个团队只能在 us-east-1 创建 t3.medium 以下的实例”。它的 drift detection 每隔固定时间扫描实际状态和声明状态的偏差，自动生成修复 plan。对于合规要求高的金融、医疗行业，这几乎是刚需。一个典型场景：某人半夜通过控制台手动改了安全组规则排查故障，第二天 Spacelift 就能发现偏差并提示你是要回滚还是接受这个变更。
env0 走的是另一个方向：开发者自助服务。它让每个团队通过一个 catalog 界面自行申请环境，背后的 IaC 代码、审批流程、成本预算全部预设好。想象一下，新来的开发者点两下按钮就能拉起一套完整的 staging 环境，不用找 SRE 排队等三天。env0 在成本管理上也下了重功夫，每次 plan 都会显示预估费用变化，还能设置预算上限——超了就自动拒绝 apply。对于那些云账单经常超支、每个月财务都来找 DevOps 对账的团队，这个功能本身就值回票价。
这两个平台都支持 Terraform、OpenTofu、Pulumi 甚至 CloudFormation 作为底层引擎。选它们的逻辑是：IaC 引擎是可替换的，但管控层是长期投资。
K8s 原教旨路线：Crossplane
团队里还有一个声音来自搞 Kubernetes 的小王。他的观点更激进：既然所有东西最终都跑在 K8s 上，为什么不用 K8s 的方式管理云资源？
Crossplane 把每个云资源都建模成 Kubernetes CRD。一个 RDS 实例就是一个 YAML manifest，apply 到集群里，Crossplane controller 帮你调 AWS API 创建出来。state 存在 etcd 里，reconciliation loop 天然处理 drift，GitOps 工具链（ArgoCD、Flux）直接复用。对于已经用 GitOps 管理应用部署的团队来说，基础设施管理可以复用同一套 PR review、自动同步的工作流，不需要再维护一套独立的 IaC pipeline。
这听起来很优雅，前提是你的团队已经深度拥抱 Kubernetes。如果你的运维人员对 K8s operator 模式了如指掌，Crossplane 会让他们如鱼得水。但如果团队里有人连 kubectl 都不太熟，强推 Crossplane 就是在制造新的知识壁垒。它的学习曲线不在工具本身，而在整个 K8s 生态的心智模型。你需要理解 controller、reconciliation、finalizer、composition 这些概念，才能在出问题的时候知道去哪里排查。
一张表看清差异
| 维度 | OpenTofu | Pulumi | Spacelift | env0 | Crossplane |
|---|---|---|---|---|---|
| 定位 | Terraform 开源替代 | 通用编程语言 IaC | IaC 编排管控平台 | IaC 自助+成本管理 | K8s 原生资源管理 |
| 语言 | HCL | TS/Python/Go/C# | 不限（编排层） | 不限（编排层） | YAML (K8s CRD) |
| 迁移成本 | 极低 | 中-高（重写） | 低（包装现有代码） | 低（包装现有代码） | 高（全新范式） |
| 开源协议 | MPL 2.0 | Apache 2.0 | 商业 | 商业 | Apache 2.0 |
| 适合谁 | 现有 TF 用户想脱离 BSL | 软件工程背景团队 | 合规驱动的大组织 | 开发者自助需求强 | 深度 K8s 团队 |
| State 管理 | 自建/S3/PG | Pulumi Cloud/自建 | 内置 | 内置 | etcd (K8s) |
| AI 能力 | 社区探索中 | 原生集成 | 有限 | 有限 | 无 |
没有人告诉你的事
选型讨论里最容易被忽略的一个变量是团队的认知负荷。五个工具都能解决”管理云资源”这件事，但它们对团队提出了完全不同的认知要求。OpenTofu 要求你会 HCL，Pulumi 要求你是程序员，Crossplane 要求你是 K8s 专家，Spacelift 和 env0 要求你理解平台工程的理念。
另一个容易被忽略的是锁定的层级在转移。从前大家怕被 AWS 锁定，后来怕被 Terraform 锁定，现在如果选了 Spacelift 或 env0，锁定点就变成了编排层。每一次选择都只是把依赖关系挪到了不同的位置，你能做的是选一个你愿意承担的锁定位置。
还有一个现实：这些工具并不互斥。不少团队在同时使用 OpenTofu 做底层声明、Spacelift 做编排管控、Crossplane 管一部分 K8s 侧的资源。工具组合的复杂度本身也是成本，但对于规模够大的组织来说，让不同子团队选用最适合自己的工具，再通过统一的管控层收口审批和合规，反而是阻力最小的演进路径。
老张最后的决定是先花两周做 PoC：OpenTofu 跑现有代码验证兼容性，同时让李明用 Pulumi 重写一个新项目的基础设施。两条路并行，三个月后看数据说话。
这大概是 2026 年最诚实的答案——没有哪个工具是银弹，但至少现在你有得选了。三年前 Terraform 一家独大的时候，连选的机会都没有。而选择本身，就是开源生态给工程师最好的礼物。
Stay updated with our latest AI insights
