Crossplane 经常被比作 HashiCorp 的 Terraform。对于企业平台团队来说随着平台增长寻找替代方案过程中，通常会用 Crossplane替代Terraform。这两个项目之间有相似之处：

• 两者都允许工程师将他们的基础设施建模为声明风格的配置

• 两者都支持使用Provider插件管理无数不同的基础设施

• 两者都是具有强大社区的开源工具

关键区别在于 Crossplane 是一个控制平面，而 Terraform 是一个命令行工具——控制平面的客户端。这篇文章触及了企业在扩展 Terraform 时通常面临的一些痛点，并强调了 Crossplane 如何解决这些问题。

一、协作

企业通常通过其运维团队采用 Terraform。对于一个小型团队来说，这是管理的基础设施的好方法。将基础设施表示为声明性配置允许运维团队从软件工程最佳实践中获益——将配置通过Git等工具管理，在必要时可以引入代码评审和回滚机制。

Terraform 是个人运维的瑞士军刀，但是在较多工程师需要协作的环境就有点力不从心了。因为Terraform 依赖于一个单一的状态文件来将记录基础设施的状态映射。在应用配置时必须Lock状态文件，因此这是一个阻塞过程时间可能需要几分钟。在此期间，没有其他工程师只能进行摸鱼操作。此外Terraform 使用的是梭哈的方式部署基础设施——因此没有推荐的方法来修改配置中的某一个基础设施。比如缓存和数据库的配置只能基于同一个状态文件进行同时更新、而无法分开更新运维。

Terraform 建议将整体配置分解为越来越细化的配置。虽然运维团队可能从“production” 配置开始，但我们鼓励他们将其分解为范围内的配置，例如“production billing”和“production auth”。很难一开始就做到这一点，因此随着时间的推移可能需要进行大量重构，并且通常会导致 Terraform 配置的复杂依赖与其输入和输出相耦合。

而Crossplane的跨平面资源模型 (XRM) 促进了松散耦合和最终一致性。在 Crossplane 中，每个基础设施都是一个支持创建、读取、更新和删除操作的 API 端点。Crossplane 并不需要向Terraform那样计算依赖关系图来进行更改，因此您可以轻松针对单个数据库进行运维操作，即使您使用 Crossplane 管理整个生产环境。

二、自助服务

现代组织正在从基础设施的集中管理演变为自助服务模型，在该模型中，平台运维团队定义了他们支持的基础设施抽象。Terraform 已经采用模块来支持这种模型。模块与软件库没有什么不同，与 Crossplane 一样，Terraform 资源是外部 API 资源的抽象表示。一个模块在这些资源的配置之上提供了一个简化的抽象——例如，RDS 模块将多个不同的 Terraform 资源抽象为一个单一的“RDS 实例”概念。

将应用程序团队视为 Terraform 配置“库”的消费者，也意味着他们受制于 Terraform 的协作限制。因此应用程序开发人员被邀请在其组织的基础架构上进行协作，这样就被绑架到了部分运维的工作。平台团队是将应用程序开发团队拉入了日常的工作会议，而不是为他们提供平台服务。这意味着应用应用团队又被安排了新的学习任务——Terraform 和 HashiCorp 配置语言 (HCL)。当然，对于应用开发人员来说获得了更高级的配置抽象，但是平台的访问管理并没有同步跟上（这是工具和平台脱轨导致）。虽然平台团队可以发布允许应用程序团队管理“RDS 实例”的模块，但访问控制仍然在云提供商 API 级别，还围绕“database subnet groups” 和 “database parameter groups”这些细节运维。

Crossplane 的XR复合资源和 Terraform 模块等价，每个 XR 资源都作为 API 端点独立公开。平台团队可以定义和记录每个 XR 的 OpenAPI 架构，并在 API 级别实施基于角色的访问控制 (RBAC)。这意味着，如果平台团队决定将他们提供给开发团队的抽象构建为“AcmeCo PostgreSQL 数据库”，他们可以同时授予 RBAC 访问权限以创建、读取、更新或删除 AcmeCo PostgreSQL 数据库，而不必再操心如 RDS 实例或子网组等各种底层云概念。由于 Crossplane 是建立在久经沙场的 Kubernetes RBAC 系统之上，平台团队可以轻松地为应用程序开发团队服务。

而且自服务在 Crossplane 中被进一步扩展，任何一个 XR 都可以提供多种服务类别。Crossplane 基于 Kubernetes 的 spec 和 status 将 XR 的输入和输出和它的实现解耦。如果应用程序开发人员已被授予创建数据库的权限，他们可以轻松地从任何服务类别中进行选择。这些服务类别可以是生产、预发或和开发；AWS、Azure 或和 GCP；或其任何组合。

三、集成与自动化

Terraform 虽然封装了很多 API 能力，但是它自己不提供 API。这导致许多团队无法通过 API 的方式将他们的 Terraform 配置提交到修订控制工作自动化。相对于从笔记本电脑运行 Terraform 的团队而言，这是一个改进，但它暴露了云原生时代尝试扩展 Terraform 使用时面临的一个关键问题。Terraform 是一个命令行工具——而不是控制平面。因为它是一个短暂的、一次性的过程，所以它只会在调用时尝试将您所需的配置与实际基础设施相协调。无论是从 CI/CD 管道还是笔记本电脑运行 Terraform 通常仅在基础设施需要更新时才会被调用。

Terraform 保守的、“按需”的方法来协调所需的实际基础设施状态可能会导致新的僵局。回想一下，应用 Terraform 配置的过程是全有或全无——如果在同一配置中描述缓存和数据库，则必须始终更新两者以更新其中一个。但是如果某个同学直接绕过 Terraform执行了某些运维操作，这将导致Terraform本地辛辛苦苦记录的状态文件失效。例如这样一个场景：一名工程师在半夜被呼叫处理一个事件，通过 AWS 控制台对生产缓存配置进行一些快速编辑，却忘记在 Terraform 中同步这些更改。

另一方面，Crossplane 构建为一系列长寿命、始终在线的控制回路。它不断地观察和纠正基础设施以匹配其所需的配置，无论是否预期会发生变化。这有效限制了团队绕过 Crossplane进行秘密运维操作。当 Crossplane 被要求管理一块基础设施时，在它之外所做的任何更改都将自动并持续地恢复。

Terraform 因为不提供API导致与其他系统集成成为一个痛点，此外它是使用域特定HCL语言的也提高了协作门槛。而Crossplane 公开的是 REST API，集成团队可以自由选择Go、Ruby或其他语言来进行集成工作。

同时Crossplane 不公开任何旧的 REST API。在 Kubernetes API 上构建意味着团队可以使用 kubectl 等工具来编排他们所有的基础设施。他们用来编排容器化应用程序的相同工具。Crossplane 甚至可以将应用程序连接到基础设施所需的详细信息，以简化集成工作。它可以与 ArgoCD、Gatekeeper 或 Velero 等项目配对，以启用 GitOps、高级策略和备份。如果需要定制自动化，与 Crossplane 集成的 Kubernetes operator 来进行扩展。

四、为什么不可兼得？

Crossplane 和 Terraform 都可以编排组织的基础设施。两者之间有相似之处，但每个项目采用不同的编排方式。Terraform 为控制平面 API 提供命令行界面，而 Crossplane本身就是一个控制平面，可用于在其他控制平面之上构建抽象。因为 Crossplane 使平台团队能够提供自己的控制平面，所以它避免了在扩展 Terraform 时面临的许多挑战。

精明的读者可能会注意到，这两个项目可以相互补充——Terraform 作为 Corssplane 的客户端界面，通过 Kubernetes Provider 允许编排 Kubernetes 控制平面！这意味着可以将 Terraform 与 Crossplane 配对，例如，如果你的小伙伴喜欢写 HCL 而不是 YAML，则可以使用 Terraform 来定义 XR 和组合。并且依然可以使用 Terraform 来plan和apply对 Crossplane 所需的状态更改！

原文：https://blog.crossplane.io/crossplane-vs-terraform/