背景

之前发了一篇《Pulumi 惊艳到我了（还可以无限免费薅 AI 羊毛） - Jeff Tian的文章 - 知乎》，有人留言希望我分享一下我们对 Pulumi 和别的方案做过的对比。

今天就来分享一下这个对比，希望有参考作用。

正如前文所说，我们之前用过 CloudFormation 甚至纯脚本的基础设施即代码，但是终于有一天受不了了，希望能够转而使用现代化的、更易于维护的方案。这种改变的主要原因有：

使用 CloudFormation 或者其他的基于yaml 或者 json之类的方案，非常难以阅读和维护
抽象级别太低，要使用 CloudFormation 进行稍微复杂一些的构建会非常麻烦。
- 比如，在 CloudFormation 中写一个条件表达式会非常混乱；又比如，要引用另外一个堆栈也很不直观；再比如，当需要在两个堆栈中共享一些代码时，又或者当需要在多个环境（开发、测试、生产等）中创建相同类型但是在不同环境中属性值不同的多个资源时，也非常困难。所有这些难点，在一种能够使用编程语言的 IaC 框架中，那都不是事儿。

考虑过的方案对比

一共对比了 4 种方案，分别是：

	Pulumi	Terraform CDK	AWS CDK	CloudFormation
参考链接	Documentation	[CDK for Terraform	Terraform	HashiCorp Developer](https://developer.hashicorp.com/terraform/cdktf)
优势	- 直观的 API 接口 - 庞大的社区群体，良好的文档 - 支持多个云厂商 - 多种编程语言可供选择，你可以选择你喜欢的 - 对自动化测试友好	- 支持多个云厂商 - 多种编程语言可供选择 - 对漂移检测支持得很好 - 对自动化测试友好	- 对自动化测试友好 - 新特性更新及时 - 多种编程语言可供选择 - 良好的文档	- 声明式 - 良好的文档
劣势	- 新特性可能会有滞后 - 使用 Pulumi Cloud 的价格不够透明	- 还在 Beta 阶段 - 不够成熟 - 新特性可能会有滞后	- AWS 专有 - 漂移检测不是最好的 - 自定义规则写起来太琐碎了 - 底层还是使用了 CloudFormation	- 漂移检测不是最好的 - AWS 专有 - 慢 - 只能用 yaml/json - 很难抽象
风险	学习曲线有点陡峭	学习曲线有点陡峭	基于了 CloudFormation，从而拥有 CloudFormation 的劣势	团队陷入了yaml/json的泥潭

经过比较后，我们对其进行了采纳的优先级排序：

我们也咨询了社区里其他使用 Pulumi 的团队，得到如下反馈：

易于测试
周围越来越多的人开始使用 Pulumi 了
只需要少量 yaml 代码，就能在诸如 GitHub Actions 的 CI/CD 流水线中运行起来
一个例子：https://github.com/Jeff-Tian/okteto-infra/actions/runs/7524112949/job/20478431724
在简单场景下并不需要使用 Pulumi Cloud
可以将已经存在的基础设施资源及状态导入到自己喜欢的编程语言中
可以使用 AWS S3 作为状态的备份
可以和代码仓库做深度集成，比如每次提交 PR 后，自动预览变化。

Bug 比 Terraform 多 —— Pulumi 尝试集中力量赶上 Terraform 所拥有的功能，所以可能在 BUG 修复上慢了一些
Pulumi Cloud 可能并不便宜，起码价格并不透明（听说有的团队在使用，需要一年支付 1 万美元）
听到有人说 Pulumi 其实比 CloudFormation 更慢，可能是由于不像其他的 IaC 框架，它的堆栈状态验证发生在操作之间，而不是在所有的操作开始之前。

Pulumi Cloud 有一些很好的功能：

我们最终采纳了 Pulumi 做为 IaC 框架，但是决定不使用 Pulumi Cloud。不使用 Pulumi Cloud 的原因是在我们的使用场景中，只会用到它的堆栈状态存储，从而一年 1 万美元的价格就显得太贵了。

额外的好处是，可以按需创建和销毁资源。我能想到的一个常见场景是，做个定时任务，每天上班定时创建出资源并部署测试环境，下班后自动销毁，从而可以节约成本。