Infrastructure as Code (IaC) tools are a crucial technology in the cloud computing world. Organizations have recently started to benefit greatly from IaC, which makes cloud resource management more efficient, reduces human error, and promotes automated deployment and greater consistency.
Hashicorp’s Terraform has been a leading IaC tool, and I have written extensively about Terraform on this blog. However, I am often asked about alternatives to Terraform.
In this post, we discuss the Terraform alternatives in no particular order. We will not dive deep into Terraform; we assume basic knowledge.
When we discuss IaC, we have to consider a generic set of features based on its usage. These are not tool-specific features, but choosing an IaC tool involves answering the following questions:
- Which language is used to write IaC?
- How does the tool maintain the relationships between the configuration and the cloud resources managed via these configurations?
- Is it cloud-agnostic or cloud adherent?
- What does a team development workflow look like?
- Is it open source or proprietary?
- What does the architecture of a particular IaC tool look like?
- What are the deployment requirements?
- Is there any plugin ecosystem or community support?
We will explore a few Terraform alternatives with respect to the above pointers and shed some light in the hope that it helps you decide on the choice of the IaC tool.
Here are some of the Terraform alternatives:
OpenTofu is an open-source Terraform alternative that will expand on Terraform’s existing concepts and offerings. Forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers, while also introducing improvements and enhancements. The project is part of the Linux Foundation, with the ultimate goal of joining the Cloud Native Computing Foundation (CNCF).
There are no differences between Terraform (versions prior to 1.5.6) and OpenTofu, but this will change as new versions emerge. Initially, it works exactly the same as Terraform, with OpenTofu being a drop-in replacement for it. OpenTofu is not going to have its own providers and modules, but it is going to use its own registry for them.
It was created by the OpenTF initiative in response to HashiCorp’s change to the BSL. The initiative is supported by many companies, some of which have even pledged to cover the costs of full-time engineers (FTE) dedicated to the project to ensure the best possible growth. Spacelift will cover the cost of five FTEs for a period of five years.
The community dictates the direction of OpenTofu, which will offer greater flexibility in the development of new features, considering what is important for the users. There are a couple of interesting feature requests already in the repository, and other features are planned, such as support for OCI provider registries and state encryption.
OpenTofu works with your existing Terraform state file so you won’t have any issues when you are migrating to it.
Key advantages of using OpenTofu instead of Terraform:
- Open-source nature: There are no restrictions on how you can use OpenTofu, either for commercial or personal use. The open-source nature of OpenTofu embodies the principles of openness and collaboration that characterize the tech community.
- Dynamic community: Developer contributions will make the project more robust and adaptable to different use cases. Bugs and issues will be identified and resolved quickly to ensure reliability and stability.
- Fast, reliable support: The growing community behind OpenTofu not only gives everyone the opportunity to influence the development of new features, but it also supplies the resources to ensure these features and bug fixes will be introduced rapidly.
- Minimal risk: OpenTofu is published under MPL and is a part of the Linux Foundation (with the goal of joining CNCF), which provides the guarantee the tool remains truly open-source, forever.
Contributing to OpenTofu can be easily done by checking the Contribution Guide. The easiest way you can contribute is by opening an issue, and every major change will be done through an RFC.
OpenTofu is the future of the Terraform ecosystem and having a truly open-source project to support all your IaC needs is the main priority.
One of the biggest advantages of using Pulumi for developing IaC is the fact that you can use programming languages you already know. Cloud resources are described using languages like TypeScript, JavaScript, Python, Go, C#, Java, and YAML. Due to this varied support, most developers already knows one of the languages, enabling them to get started with Pulumi.
At a high level, Pulumi’s architecture consists of a language host, where the script files are developed, a CLI and deployment engine that create the cloud resources based on the scripts, and also ensure consistency, and a state management mechanism where the last deployed state information is stored for future operational reference.
(image copied from the Pulumi docs here)
The state is usually managed in Pulumi Service – a service hosted online – which is a default choice for any operation performed. However, it is possible to self-host this service and use it internally. Additionally, Pulumi also supports state backends like AWS S3, Azure Blob Storage, and Google Cloud Storage. State management is also possible on the local filesystem with an explicit –local flag.
Infrastructure expressed using one of the languages in Pulumi is considered to be declarative. When Pulumi binary executes the program files, it feeds the information related to the desired existence of a cloud resource to the deployment engine. The deployment engine in turn checks against the state backend and decides whether to create, update, or delete the resource.
Pulumi SDK for the language of your choice, makes use of provider plugins that consist of resources. A provider in Pulumi corresponds to a cloud platform such as AWS, Microsoft Azure, and GCP. A resource corresponds to the services these cloud platforms provide. Providers use cloud platform APIs to perform the deployment operation as per the supplied program files.
Pulumi is a cloud-agnostic IaC tool with a growing community. It supports a range of cloud providers including AWS, Azure, and Google Cloud.
Check out Pulumi vs. Terraform.
CloudFormation is a service provided by AWS to manage cloud resources in a more automated, reliable, consistent, and predictable manner. As the name suggests, AWS CloudFormation is a service provided by AWS, thus it is used to design, deploy, and manage AWS infrastructure.
Infrastructure is defined using CloudFormation templates, which use JSON or YAML syntax. This is a very familiar and user-friendly format, so you can get started with CloudFormation templates quickly. However, given the abundance of services and related attributes, it is not straightforward to define the infrastructure in CloudFormation templates from scratch.
This is where the CloudFormation Designer comes in. CloudFormation Designer is an editor which helps you build CloudFormation templates from scratch. The simple drag-and-drop interface helps developers design their infrastructure requirements by selecting the components they need in their architecture and setting various attributes related to it. The CloudFormation designer simultaneously displays the output of the template on the same screen.
Once the CloudFormation template is created and validated to create the infrastructure as defined, the infrastructure thus created is stored as a Stack. A Stack is a set of infrastructure managed using a specific Template. The Stack also provides various parameter and attribute information.
For example, it keeps track of the events of creating and destroying the infrastructure, performs drift detection, protects from accidental termination, outputs the desired values from the infrastructure creation events, etc.
When we update an existing infrastructure managed by CloudFormation templates, Change sets are created. Change sets provide a way to preview the changes which will be applied. They highlight the creation, deletion, and update activities that will be performed due to the modified CloudFormation templates.
AWS CloudFormation templates help manage AWS infrastructure in a streamlined and consistent manner, with less possibility of human error. AWS also provides a number of quick-start templates with pre-defined solutions. All the actions performed using the AWS CloudFormation web console can also be performed using AWS CLI. AWS also maintains a CloudFormation-specific CLI.
Learn more: Terraform vs. AWS CloudFormation: The Ultimate Comparison
Azure ARM templates serve a similar purpose for Azure as CloudFormation Templates do for AWS but with a few differences. To start Azure Resource Manager (ARM) Template is the Azure-native way to manage infrastructure as code.
ARM templates use JSON format to declare the desired state of infrastructure. A couple of ways to develop ARM templates are to use VS code extension developed by Microsoft to create ARM templates, and on the Azure portal as well.
Infrastructure in Azure is managed with respect to the subscription ID and resource group. ARM templates act as inputs to Azure Resource Manager, which interprets these templates and performs appropriate REST API calls to provision the resources. The resources thus created are always associated with a particular subscription and resource group.
There are several ways to work with ARM templates. After the portal, the most common options to deploy ARM templates are Azure CLI and PowerShell CLI. Verification of the deployment is performed by visiting the Resource Group page, which provides details about the successful and failed deployments.
The ARM templates implement the function to accept input variables as well as generate the output variable values after successful deployment. They also support certain template functions, which help in querying the resources during runtime. This helps build dynamic and flexible ARM templates by not requiring to hardcode certain values.
Unlike AWS CloudFormation change sets, when the ARM templates are updated with new resources or by removing the older resources, there is no verification step before the action is triggered.
Google Deployment Manager is a service provided by Google Cloud Platform (GCP) to recreate compute environments in a predictable manner. Unlike AWS and Azure, the solution provided by Google Deployment Manager is not a full-fledged IaC solution but does assist in creating certain infrastructure components in GCP on a use-case basis.
Infrastructure is defined in YAML formatted configuration files. Every infrastructure component is represented as a resource in configuration files, and every resource has a type attribute that lets the deployment manager understand which REST APIs to use to provision the resource.
Each configuration file represents a single deployment. Every deployment has a user-defined name, which is used to access and analyze the status of deployment on the web console. To manage multiple resources in a single deployment, Templates are used as reusable building blocks. Templates are developed using Python or Jinja2 templating language.
To deploy the configuration using Google Deployment Manager, Google Cloud CLI is used. Google Cloud CLI comes bundled with deployment-manager function to process the configuration YAML files.
The information about the deployed components using the deployment manager is stored in a read-only object. This object is called manifest and is an equivalent of the state file in Terraform. However, there is not much to manage as it only provides information for the currently deployed configuration. Any following update to the configuration deployment creates a new manifest.
There is no verification step involved when updating the deployment using configuration files. Instead, care has to be taken manually while making changes to the deployed configuration. For example, the existing dependencies of any resource being replaced have to be verified before deploying the configuration.
As mentioned earlier, Google Deployment Manager is a solution that is use-case-specific and works well for managing deployments within GCP. However, it is not a complete IaC tool with all the bells and whistles we expect from other IaC solutions.
If we want to deploy cloud applications on AWS while developing the IaC using familiar programming languages, AWS CDK is the right choice. With AWS CDK, you can develop IaC on AWS in the same IDE while leveraging the advantages offered by CloudFormation Templates.
As seen in the AWS CloudFormation section, it offers several infrastructure management features using IaC in the form of JSON and YAML. AWS CDK leverages all those features but allows developers to express and deploy their infrastructure using programming languages like Typescript, JavaScript, Go, C#, Python, and Java.
However, AWS CDK offers far more than leveraging CloudFormation features in familiar programming languages. It is a way to develop the applications and the infrastructure these applications are hosted on, in the same IDE. Thus, every iteration results in a fully deployed and functional application.
AWS CDK uses of constructs, which define infrastructure components with proven defaults and flexibility to change them. The AWS Constructs library provides constructs for many AWS services that help in wrapping the complexity as well as taking care of interconnectivity between multiple services.
Multiple constructs are put together to form a Stack, which is analogous to CloudFormation Stacks. Similarly, multiple Stacks can be part of a single App, thus enabling the interconnectivity between services included in multiple stacks. It is also possible to import existing CloudFormation templates into AWS CDK, and vice versa.
AWS Constructs also correspond to the CloudFormation resource types. These constructs come in three flavors.
- L1 – with a 1:1 correspondence to the CloudFormation service. It is as good as using the AWS CDK version of the CloudFormation template defined for any service on AWS.
- L2 – also known as curated, is use-case specific construct that may employ one or more AWS services to satisfy a specific use case.
- L3 – these are pattern-level constructs that define the end-to-end architecture of an application.
AWS CDK comes with a developer-friendly CLI that helps initialize a new application infrastructure, modify existing infrastructure, analyze the changes before deployment, and finally deploy the infrastructure.
Given its support for multiple programming languages, AWS CDK offers much more flexibility as compared to CloudFormation templates. However, since it synthesizes CloudFormation templates under the hood, it is adherent to the AWS cloud platform.
CDKTF is a cloud development kit by Hashicorp. Hashicorp is already known for its IaC tool, Terraform. Terraform uses the proprietary language known as Hashicorp Configuration Language (HCL) as well as JSON. However, if we want to leverage the knowledge of familiar programming languages like Typescript, Python, Java, C#, and Go to develop the infrastructure, CDKTF is the preferred option.
It is similar to AWS CDK, but we leverage the end-to-end infrastructure lifecycle management abilities offered by Terraform, and it is also cloud agnostic. Unlike AWS CDK, CDKTF converts the script file written in the language of choice into Terraform configuration files in JSON format.
CDKTF has its own set of CLI commands, which help initialize the project, generate the Terraform config files, and deploy resources to the respective cloud platform. Even though Terraform is the underlying operational layer, we do not have to worry about the Terraform CLI commands.
Another important component in CDKTF is the cdktf package which contains the core libraries that help us convert our scripts to Terraform configuration files. Using cdktf it is possible to convert the existing Terraform configuration defined in HCL to the preferred language in CDKTF. However, the configurations defined in CDKTF can only be translated to JSON-formatted Terraform configuration.
CDKTF employs an application design architecture that is similar to AWS Constructs. Here the applications are wrapped into an app, which may contain multiple Stacks, and each Stack is a collection of multiple cloud resources. Resources defined in Stacks that are part of the same application can communicate with each other.
CDKTF is becoming more popular as it allows developers to develop infrastructure by using the programming language familiar to them, at the same time leveraging the infrastructure lifecycle management capabilities of Terraform.
Microsoft Bicep is an open-source domain-specific language that provides a syntax to deploy Azure resources. Since this is a domain-specific language, it has its own set of syntax which might add a learning curve for developers. It is also not cloud-agnostic as it works with Azure Resource Manager to create and manage Azure cloud components.
As discussed in earlier sections, ARM templates use JSON format to express the IaC, which can become a bit cumbersome when developing large sets of infrastructure. Microsoft Bicep allows for a programming experience that results in an easily traceable IaC.
Under the hood, Bicep files are submitted to Azure Resource Manager, which then provisions the resources on the Azure cloud.
Developing IaC using Microsoft Bicep supports modularity, where you can develop and reuse infrastructure components. It also implements a verification step where we can see the operations that would be performed before actually executing them.
As far as state management is concerned, all the state information is stored in Azure. There is not much that can be done with this information apart from querying.
Red Hat Ansible is primarily a configuration management tool. It has many product features, but for the sake of this post, we will limit our discussion to IaC and infrastructure lifecycle management capabilities offered by Ansible.
Ansible works on the concept of an Ansible playbook. This is a YAML formatted file that describes the sequence of activities that should be performed by the Ansible host. This principle also applies to public cloud provisioning.
Ansible is cloud-agnostic. It supports hundreds of modules for AWS, GCP, OpenStack, and Microsoft Azure, where it helps manage compute, databases, networks, containers, and related infrastructure.
Unlike other tools for configuration management, such as Chef, Puppet, and Salt Stack, Ansible is agentless. This eliminates the need for agent installation for managing software patches and application versions on the target host machines. Instead, Ansible relies on SSH for Unix-based OS and WinRM for Windows OS to log into the resources and perform actions.
This ability allows Ansible to manage the resources it provisiones. There is no explicit state management with respect to the infrastructure itself and no provision of previewing the potential changes to the infrastructure.
As mentioned earlier, Ansible is geared toward configuration management, so it may not be the best choice for infrastructure management. However, using Ansible in conjunction with another IaC tool can be a great combination for any organization’s automation aspirations.
See the detailed comparison: Terraform vs. Ansible : Key Differences and Comparison of Tools
Crossplane is integrated inside a K8s cluster, allowing users to provision and manage cloud infrastructure resources using Kubernetes-style declarative configurations. This not only provides a consistent API-centric approach to infrastructure management but also facilitates seamless integration with existing Kubernetes workflows, operators, and tools. In a sense, Crossplane resembles a K8s operator for cloud providers, having a similar approach to defining and deploying the infrastructure inside the cluster.
As it is deployed inside K8s, you can take advantage of Helm and Kustomize when you are declaring your infrastructure resources. You can also leverage ArgoCD, Flux, and Spacelift to deploy your Crossplane resources.
If you are not using a K8s cluster, the overhead of installing, configuring, and managing it may not be worth the effort, but it can make sense to use it if you are already invested in Kubernetes.
See comparison Crossplane vs Terraform.
Alternatives to Terraform cater to a range of infrastructure-as-code needs. Your options from competitors include OpenTofu, Pulumi, AWS CloudFormation, Ansible, Crossplane, and others. Each offers different features and capabilities, so careful comparison will help you decide which one best suits your organizational goals and technical environment.
We encourage you also to explore how Spacelift makes it easy to work with Terraform. If you need any help managing your Terraform infrastructure, building more complex workflows based on Terraform, and managing AWS credentials per run, instead of using a static pair on your local machine, Spacelift is a fantastic tool for this. It supports Git workflows, policy as code, programmatic configuration, context sharing, drift detection, and many more great features right out of the box. You can check it for free by creating a trial account or booking a demo with one of our engineers.
Terraform Management Made Easy
Spacelift effectively manages Terraform state, more complex workflows, supports policy as code, programmatic configuration, context sharing, drift detection, resource visualization and includes many more features.
