Table of Contents
Modern applications are designed with scalability, reliability, and multicloud compatibility in mind. These applications rely on a diverse range of infrastructure resources, which can be challenging to manage manually. Infrastructure as code (IaC) technology has emerged to address this challenge. IaC enables developers to define the entire infrastructure required for an application in a configuration file. With the help of this file, the infrastructure can be automatically provisioned and managed. Terraform and Crossplane are two popular tools that provide IaC solutions.
Developed by HashiCorp, Terraform is an open source IaC tool that lets you define and manage your cloud and on-premise infrastructure in a declarative manner using configuration files that can be versioned, reused, and shared across platforms.
Crossplane is a modern control plane that is used for provisioning infrastructure in Kubernetes clusters. Built on top of Kubernetes, Crossplane as a control plane extends the ability of Kubernetes clusters to provide, orchestrate, and manage cloud infrastructure resources using Kubernetes tools and APIs.
While Terraform is one of the most widely used tools, it has some limitations that Crossplane usually resolves. Enterprise platform teams commonly discover Crossplane while looking for alternatives after outgrowing Terraform. This article covers the major differences between these two tools based on the following:
- Core functions
- Architecture
- Configuration type
- Licensing
- Community support
- Vendor support
- CI/CD integration and automation
- Developer experience
#Terraform
Terraform simplifies the process of managing an application’s infrastructure by allowing teams to manage the entire infrastructure using a configuration file, regardless of the application’s vendor. Terraform uses a domain-specific language (DSL) called HashiCorp Configuration Language (HCL) to provision and manage the infrastructure.
The core workflow of Terraform comprises three stages:
- Write: You declare the infrastructure resources as code written in HCL. These resources can be from multiple vendors. For instance, a practical example could involve connecting to Amazon S3 buckets to read data for your application.
- Plan: As mentioned, Terraform maps the desired infrastructure over the current state of infrastructure. Terraform then compares the declared state of infrastructure with the current state and creates an execution plan to add, remove, or modify the necessary resources.
- Apply: If the plan is approved by the developer, the operations specified in the configuration file are executed to achieve the desired infrastructure state.
#Terraform Architecture
There are three high-level components in Terraform’s architecture:
- Terraform Core: Written in the Go programming language, Terraform Core is a statically compiled binary. The Terraform CLI, which is the primary interface for Terraform users, is a compiled binary generated by Terraform Core. The Core is responsible for parsing the configuration files (containing infrastructure configuration), execution planning, resource provisioning, and resource state management.
- Providers: Terraform uses plugins called Terraform providers to interact with cloud providers, SaaS providers, and other APIs. The Terraform providers contain all the necessary logic to connect to specific services offered by different cloud providers. Before you can use them, you need to declare the providers you need in your Terraform configuration so that Terraform can install them. You can find all widely used Terraform providers, such as AWS, Azure, and Google Cloud, in the Terraform Registry.
- A state file: Terraform requires a state file to map physical resources to your configuration, enabling it to control and manage the infrastructure efficiently. This file, typically named
*.tfstate, stores metadata, resource details, current state, and dependencies. Keeping this file secure is crucial due to its sensitive information regarding the managed infrastructure.
Terraform enables infrastructure as code to manage the entire lifecycle of the infrastructure used in a particular project. IaC makes it much easier to provision and manage the infrastructure with the help of declarative language, making it more consistent, repeatable, and reliable. Using a configuration file, Terraform also allows different developers to work on the same file, making collaboration easier.
#Configuration Type
Terraform is a declarative tool, which means you just need to define the desired state of the infrastructure. You don’t need to perform the step-by-step execution of the same; Terraform will determine how to achieve that state for you. To learn more about configuring infrastructure using HCL, you can refer to this article.
#Licensing
Terraform is an open source tool released under the Mozilla Public License, version 2.0, which means you can use, modify, and distribute the software. Any changes you make to the software also need to be under the Mozilla Public License and must be made available to others.
Along with the free version, Terraform also provides cloud and enterprise editions. More details about these Terraform editions can be found here.
#Community Support
As Terraform is a well-established open source project, it has a vibrant and active community with dedicated users willing to provide support through various channels. For instance, the Terraform community maintains discussion forums on HashiCorp and Reddit.
Terraform also has well-maintained, comprehensive, and technically rich documentation. Additionally, Terraform’s source code is hosted on GitHub, so you can raise issues, create pull requests, or contribute to the current development of features.
#Vendor Support
Terraform can connect to different resources and services provided by around 130 different vendors. The vendor list supported by Terraform includes cloud providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP); infrastructure platforms such as VMware, OpenStack, and Kubernetes; and some third-party tools and libraries to connect with different providers supported by Terraform.
#CI/CD Integration and Automation
Terraform supports fully operating via CLI (for the community edition), API, and UI (for the cloud and enterprise editions), which means you can easily integrate Terraform with your existing CI/CD pipelines. You just need to use a version control system such as Git and commit your Terraform configurations as part of your existing CI/CD pipeline. However, Terraform operates solely as a command line tool and performs the reconciliation between the desired infrastructure state and the current state only when it is explicitly invoked. As a result, it becomes your responsibility to monitor the infrastructure for any inconsistencies. If inconsistencies are identified, you need to manually trigger the script, which can be a time-consuming and tedious task.
#Developer Experience
Terraform is a developer-focused tool that uses declarative language via HCL to define and manage infrastructure. If you work with any programming language, learning HCL can be quite easy for you. After using Terraform, you can treat infrastructure provisioning as a software development process, fostering collaboration, version control, and automation.
#Crossplane
Crossplane is a control plane that connects any Kubernetes cluster to external, non-Kubernetes resources such as storage, networking, and computers. When Crossplane is installed on a Kubernetes cluster, users need not worry about external resources, as Crossplane does everything for them. It uses custom resource definitions (CRDs) to represent the external resources as native Kubernetes objects, which enables you to use standard Kubernetes commands.
#Crossplane Architecture
The Crossplane architecture has four different components:
- Providers: Providers are the external entities that offer different resources such as storage, compute, DNS, networking, and so on. Some major cloud providers include AWS, Azure, and GCP. These providers are not part of the cluster, but Crossplane connects them with Kubernetes clusters to use their resources.
- Managed resources: Providers offer various resources that applications can use. When a resource is created and monitored through Crossplane, it’s considered a managed resource. Crossplane introduces this real-world infrastructure into the control plane to make it available as an extension to the Kubernetes API. A unique managed resource is created using the provider’s CRD. For instance, Crossplane builds a bucket managed resource inside the Kubernetes cluster connected to an Amazon S3 storage bucket using the AWS provider’s bucket CRD.
- Composite resources: A set of provisioned managed resources creates a composite resource. A unique abstraction or API is created by composing various resources, configurations, and policies together. This API is then made available to developers for self-service access to infrastructure. As composite resources are cluster-scoped, they are usually available to all cluster namespaces.
- Claims: Claims are the means through which a user interacts with Crossplane. When the user requires infrastructure for their application, they create a claim, and Crossplane works to provision that infrastructure for them.
Unlike Terraform, which has a Kubernetes provider to provision Kubernetes resources and is not inherently Kubernetes-centric, the main purpose of Crossplane is to extend the Kubernetes declarative API and control plane. This allows you to treat the external infrastructure and services as Kubernetes resources, enabling infrastructure as code practices and a Kubernetes-native experience. Crossplane empowers developers with self-service infrastructure provisioning, automation, and efficiency while leveraging Kubernetes' ecosystem and tooling.
#Configuration Type
Similar to Terraform, Crossplane is also declarative. With Crossplane, you define the desired state of the infrastructure and services using declarative code or manifests, and Crossplane then tries to map the desired state on the current state of the infrastructure. Although it’s declarative, you may need to directly interact with the control plane of Crossplane when provisioning or managing specific resources or performing certain actions—for example, when creating composite resources or defining different resource classes.
#Licensing
Crossplane is an open source tool released under the Apache License Version 2.0. You’re free to use the tool for any personal or organizational purpose without any restrictions or boundaries. Still, it’s a good idea to read the full terms and conditions of the license before using Crossplane.
#Community Support
Compared to Terraform, Crossplane is still a new technology. However, it has an active and growing community supporting and contributing to the project’s development. Crossplane’s source code is hosted on GitHub, which allows for strong collaboration. Apart from this, the Crossplane community has a dedicated Slack channel where users can engage in discussions. Crossplane also provides good documentation and tutorials to get started.
#Vendor Support
Crossplane supports a variety of cloud vendors and infrastructure providers. The project is designed to be vendor-agnostic, allowing users to manage resources across a wide range of cloud providers and infrastructure platforms. Some of the well-known vendors are AWS, Azure, GCP, VMware, and Alibaba Cloud.
#CI/CD Integration and Automation
Similar to Terraform, Crossplane can also be integrated with CI/CD pipelines. Crossplane features a set of long-lived, always-on control planes that continuously observe the application’s infrastructure and make the necessary changes to achieve the desired state of infrastructure. Various CI/CD platforms provide plugins and integrations for Kubernetes, making it easier to incorporate Crossplane into your existing workflows. Unlike Terraform, you don’t need to manually invoke Crossplane. Instead, it will automatically trigger when used with Argo CD whenever needed.
#Developer Experience
As a declarative tool, Crossplane also provides a developer-friendly experience for managing infrastructure and services using Kubernetes-native tools and services. When working on Crossplane, you need to have specific knowledge of Kubernetes in order to configure your Kubernetes cluster to run Crossplane. You also need to know a vendor’s infrastructure and services to use them with Crossplane. This control plane is also more approachable for those who are not deeply familiar with Kubernetes, thanks to Crossplane Compositions.
#Crossplane or Terraform: Which One Is Right for You?
As you can see, there are several similarities between Terraform and Crossplane. So, choosing which to adopt for your use case can be confusing. Terraform is a mature and widely adopted IaC tool, but it has some limitations. As organizations grow, platform teams often seek alternatives like Crossplane to overcome these limitations.
The following are some examples of these limitations and how Crossplane helps to resolve them:
- Drift: In Terraform, changes made to infrastructure resources without updating the specification file can lead to unnoticed drift until a fresh Terraform modification is introduced. However, Crossplane acts as an always-on control plane, instantly and persistently undoing any changes made outside of its maintained infrastructure.
- Collaboration: Applying configurations with Terraform involves a blocking process where a lock is applied to the state file until the configurations are applied, causing potential delays. Additionally, to modify a piece of infrastructure, you need to update dependent infrastructure as well. In contrast, Crossplane treats each infrastructure piece as an independent API endpoint, enabling simultaneous independent changes without lock conditions.
- Increased complexity: Terraform is suitable for managing a limited number of infrastructure resources. However, as your application and infrastructure requirements grow, managing Terraform itself becomes an overhead. Crossplane mitigates this complexity with familiar Kubernetes tools and services, reducing the overhead for existing setups.
#Can Terraform and Crossplane Be Used Together?
If you’re unsure about which tool to choose or if you find desirable features in both, it’s actually possible to use Terraform and Crossplane together. Since Terraform acts as a command line interface (CLI) over control planes and Kubernetes provides the capability to manage its control planes, it’s possible to use Terraform on top of Crossplane.
By combining their strengths, you can leverage the broad provider ecosystem and robust infrastructure provisioning capabilities of Terraform, along with the declarative Kubernetes-native management capabilities of Crossplane. Combining the two can bring benefits like infrastructure provisioning flexibility, Kubernetes-native resource management, IaC practices, ease of use in multicloud and hybrid environments, and improvements to automation and continuous delivery.
#Conclusion
This article compared two widely used infrastructure management tools, Terraform and Crossplane. While both tools are declarative, Terraform is a dedicated IaC tool, while Crossplane serves as a control plane. Both tools are available for free, but Terraform offers additional features with a pricing scheme. In terms of community support, Terraform has a more mature community compared to Crossplane. Both tools offer support for various providers, can be seamlessly integrated into CI/CD pipelines, and are comprehensive and developer-focused. You also saw how Crossplane effortlessly addresses some of the issues associated with Terraform.
It’s worth noting that these tools can also be used together to enhance flexibility in infrastructure management.
Ultimately, the choice between Terraform and Crossplane should be based on your specific project requirements, infrastructure needs, and preferences regarding tooling, ecosystems, and community support.
