IaC Tools Compared: Terraform vs Pulumi vs SST

什么是基础设施即代码？

基础设施即代码（IaC）是通过机器可读文件配置和管理云资源的过程，实现自动化和可复制的流水线，与手动部署过程相反。IaC 带来诸多好处：一致且可重复的部署、减少人为错误风险、版本控制及其所有优势、通过代码本身实现基础设施的实时文档化等。

随着时间推移，许多编程语言为满足不断变化的需求而创建，多种工具也应运而生以提供 IaC 能力。评估 IaC 工具的关键关注点包括：

• 云提供商支持的多样性
• 生态系统成熟度（文档和培训材料的质量、集成能力）
• 开发者体验（部署速度、本地开发能力、语言语法熟悉度）
• 模块化（定义和重用基础设施组件的能力）
• 可测试性
• 可见性（已部署资源的监控、部署指标）
• 安全性（秘密管理、合规性检查、可审计性）

Terraform

Terraform 是 HashiCorp 于 2014 年创建的 IaC 工具。它使用专有的领域特定语言 HCL 来定义基础设施。Terraform 支持几乎所有云提供商，并在 DevOps 社区广泛采用。Terraform 采用声明式方法，用户定义期望的最终状态，其状态文件跟踪实际资源以确定部署期间所需的更改。

优势

• 被许多大型组织使用，Terraform 已展示企业级就绪性，是一项成熟的技术。
• Terraform 支持几乎所有云提供商，使其成为最多功能的 IaC 工具之一。
• 官方文档全面，包含大量示例和教程。
• Terraform 拥有活跃的社区和广泛的采用，使得有经验的从业者更容易找到。此外，HashiCorp 提供认证，可能有助于筛选过程。
• Terraform Cloud 以有竞争力的价格提供可见性和安全功能。

挑战

• Terraform 需要使用 HCL 和专门的 Terraform 特定知识及工具。这鼓励了软件工程师与 DevOps 专家之间的分工，这越来越被视为阻碍生产力，尤其是在较小的团队中。
• Terraform 代码难以保持 DRY（不要重复自己），HCL 有时缺乏更具表现力的编程语言中可用的有用功能。

Pulumi

Pulumi 由前微软员工于 2017 年创建，并于 2018 年开源。它使用主流编程语言（TypeScript、Python、Java 等）定义基础设施。与 Terraform 类似，Pulumi 支持多种云提供商，并越来越受欢迎。它也采用比较期望状态和实际状态的声明式方法。

优势

• 通过支持主流编程语言，Pulumi 鼓励在全栈团队中更紧密地集成 DevOps 实践。语言熟悉度有助于软件工程师参与基础设施定义。
• 使用编程语言可实现强大的开发者工具优势，包括 IDE 支持和强静态类型。
• 高可测试性，支持单元测试、属性测试和集成测试。
• 通过本地语言结构实现高模块化，因为代码重用由现代编程中可用的各种抽象技术驱动。
• 虽然不如 Terraform 的提供商生态系统广泛，但 Pulumi 支持多种云提供商。此外，Terraform 提供商可以桥接以与 Pulumi 一起使用，并提供缺失的功能。
• 秘密在状态文件中静态加密。
• Pulumi Cloud 提供高级可见性和安全功能，尽管价格高于 Terraform Cloud。

挑战

• 尽管 Pulumi 的采用和支持在增长，但其文档和示例远不如 Terraform 全面。即使在编写 Pulumi 代码时，我经常查看 Terraform 文档和示例以弄清楚如何做事。
• 编程语言提供的高度灵活性使得软件工程文化较弱的团队更容易自找麻烦，编写难以维护的代码。
• Pulumi 支持的所有语言都具有功能对等性，但用户报告使用 TypeScript 和 Python 的体验更顺畅，尤其是在文档方面。
• 与 Terraform 相比，有经验的从业者可能更难找到和筛选。

SST

SST 创建于 2020 年，在目标上与 Terraform 和 Pulumi 有根本不同。Terraform 和 Pulumi 使用不同方法实现类似目的，而 SST narrowly 专注于 AWS 无服务器服务，旨在通过提供高级、有主见的 API 来配置云资源，从而提高开发速度。例如，虽然使用 Next 或 Remix 部署服务器端渲染应用程序可能需要大量的工程努力和基础设施代码（通过 Terraform 或 Pulumi 使用低级组件），但 SST 将其视为单个可声明资源。此外，SST 带有强大的 Live Lambda 功能，通过在开发期间代理调用到本地部署，实现 AWS Lambda 函数的热重载。

SST 在底层使用 Pulumi 引擎来管理和配置资源，并允许用户除了使用 SST 的构造之外编写 Pulumi 代码，使得没有关联 SST 构造的资源仍然可以被定义和部署。

优势

• 有主见的高级 API 显著减少支持模式的开发努力。
• Lambda 函数的热重载为无服务器后端开发者提供非常快速的反馈循环。

挑战

• 专门支持 TypeScript 作为基础设施代码的语言。
• 尽管 SST 可通过 Pulumi 代码扩展，但 SST 构造本身 narrowly 专注于 AWS 无服务器。
• 相对较新且规模小，文档和社区采用有限。
• SST 有自己的 CLI，无法连接到 Pulumi Cloud。虽然 SST 提供自己的监控解决方案（SST Console），但远未达到与 Pulumi Cloud 的功能对等性。

星级评分摘要

注意：对于 SST，大多数评分假设 AWS 无服务器被选为主要基础设施技术。

选择合适的工具

就像软件架构中的几乎每个决策一样，答案是“视情况而定！”。为了帮助指导选择哪种工具，我建议考虑有利于或不利于给定工具的标准。标准包括：

• 项目时间线（我们需要非常快地交付项目，还是有更多时间？）
• 项目风险（如果项目出现问题，对组织有多关键？）
• 基础设施需求（我们需要使用特定的架构或特定的云提供商，还是可以自由选择？）
• 团队规模和组织实践（我们有一个紧密集成的全栈团队，还是有独立的团队负责后端、前端和基础设施？）
• 团队对不同选项的熟悉度

对于每个工具，我强调了我认为可能最合适的项目特征：

SST

• 短期项目
• 低风险项目（原型设计、早期初创公司）
• 主要坚持使用 AWS 无服务器是一个可接受的约束
• 小型、紧密集成的团队
• 团队熟悉 TypeScript

Pulumi

• 长期项目
• 中到高风险项目
• 大多数基础设施约束是可接受的，尽管必须检查较少知名云服务的提供商支持
• Pulumi 鼓励具有 [T 型专家] 的集成团队担任 DevOps 角色
• DevOps 专家熟悉 TypeScript 或 Python（或任何其他支持的语言，但风险较高）

Terraform

• 长期项目
• 高到关键风险项目
• 任何基础设施约束都是可接受的
• DevOps 工程师和软件工程师之间有明确的界限
• DevOps 工程师熟悉 Terraform 及其生态系统