Infrastructure as code (IaC) tools are a crucial technology in cloud computing. 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.
In this post, we discuss 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?
To help you choose the right IaC tool, we will explore a few Terraform alternatives related to the pointers above.
Here are some Terraform alternatives:
Spacelift is an IaC management platform that helps you implement DevOps best practices and enhances your Terraform, OpenTofu, Terragrunt, Kubernetes, Ansible, Pulumi, and CloudFormation workflows.
Spacelift takes managing Terraform to the next level by giving you access to a powerful CI/CD workflow and unlocking features such as:
- Multi-IaC workflows – Combine Terraform with Kubernetes, Ansible, and other IaC tools such as OpenTofu, Pulumi, and CloudFormation, create dependencies among them, and share outputs.
- Policies (based on Open Policy Agent): Spacelift uses OPA to implement policy as code, and these policies can control various decision points throughout the application. With Spacelift’s policies, you can define which resources your team can create, what kind of parameters those resources can have (for example, you can restrict an EC2 instance type to a shape you want), the number of approvals you need for a deployment, where to send notifications, what happens when a pull request is open, and more.
- Integrations with any third-party tools: Spacelift can integrate with any tool you want, lets you bring your own Docker image, and also allows you to control what happens before and after every runner phase.
- Build self-service infrastructure: Spacelift’s Blueprints can be really helpful for building self-service infrastructure, especially for development teams that need to build infrastructure but don’t want to touch any IaC.
If you want to learn more about what you can do with Spacelift, check out this article.
OpenTofu is an open-source Terraform alternative that expands on Terraform’s existing concepts and offerings. Forked from Terraform version 1.5.6. It retains 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 is changing as new versions emerge. Initially, it worked exactly the same as Terraform, with OpenTofu being a drop-in replacement for it. OpenTofu does not have its own providers and modules, but it uses its own registry for them.
It was created by the OpenTF initiative in response to HashiCorp’s change to the BSL. Many companies support the initiative, and some 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 five years.
The community dictates the direction of OpenTofu, which will offer greater flexibility in developing new features, considering what is important for users. OpenTofu works with your existing Terraform state file, so you won’t have any issues when you migrate 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 allows everyone to influence the development of new features and 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 guarantees that the tool will remain truly open-source forever.
- State encryption: The ability to encrypt the state and ensure your secrets stay safe
Check the Contribution Guide to learn how to contribute to OpenTofu. The easiest way to do so is by opening an issue, and every major change will be made through an RFC.
OpenTofu is the future of the Terraform ecosystem, and the main priority is having a truly open-source project to support all your IaC needs.
One of the biggest advantages of using Pulumi for developing IaC is 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 know 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 creates the cloud resources based on the scripts and also ensures consistency, and a state management mechanism where the last deployed state information is stored for future operational reference.
The state is usually managed in Pulumi Service, a service hosted online, which is the default choice for any operation performed. However, it is possible to self-host this service and use it internally. Additionally, Pulumi 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 declarative. When the 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 uses provider plugins that consist of resources. In Pulumi, a provider 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 provided by AWS to design, deploy, and manage AWS infrastructure.
Infrastructure is defined using CloudFormation templates, which use JSON or YAML syntax. The format is very familiar and user-friendly, so you can get started with CloudFormation templates quickly. However, the abundance of services and related attributes makes it difficult to define the infrastructure in CloudFormation templates from scratch.
This is where the CloudFormation Designer comes in. CloudFormation Designer is an editor that 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 related attributes. The CloudFormation designer simultaneously displays the template’s output on the same screen.
The CloudFormation template is created and validated to create the infrastructure as defined. This infrastructure is stored as a stack — a set of infrastructure managed using a specific template that also provides various parameter and attribute information.
For example, it tracks the events of creating and destroying the infrastructure, performs drift detection, protects against accidental termination, and outputs the desired values from the infrastructure creation events.
Updating an existing infrastructure managed by CloudFormation templates creates change sets, which provide a way to preview the changes that will be applied. They highlight the creation, deletion, and update activities that will be performed due to the template modifications.
AWS CloudFormation templates help manage AWS infrastructure in a streamlined and consistent manner, with less potential for 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, the 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. You can develop ARM templates using the VS code extension developed by Microsoft to create ARM templates and also on the Azure portal.
Infrastructure in Azure is managed according to the subscription ID and resource group. ARM templates act as inputs to ARM, 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.
After the portal, the most common options for deploying ARM templates are Azure CLI and PowerShell CLI. The deployment can be verified by visiting the Resource Group page, which provides details about successful and failed deployments.
The ARM templates implement the function to accept input variables and generate 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 the hardcoding of certain values.
Unlike AWS CloudFormation change sets, when the ARM templates are updated with new resources or older resources are removed, the action is triggered without any preceding verification step.
Google Deployment Manager is a service provided by Google Cloud 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 Google Cloud on a use-case basis.
Infrastructure is defined in YAML-formatted configuration files. Every infrastructure component is represented as a resource in these files, and each resource has a type attribute that lets the deployment manager understand which REST APIs to use to provision it.
Each configuration file represents a single deployment. Every deployment has a user-defined name, which is used to access and analyze its statust on the web console. Templates are used as reusable building blocks to manage multiple resources in a single deployment. They are developed using Python or Jinja2 templating language.
Google Cloud CLI is used to deploy the configuration using Google Deployment Manager. It comes bundled with a deployment-manager function to process the configuration YAML files.
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 little 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, so it is important to take manual precautions when 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 use-case-specific solution and works well for managing deployments within Google Cloud. However, it is not a complete IaC tool with all the bells and whistles we expect from other IaC solutions.
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 the ability to leverage CloudFormation features in familiar programming languages. It is a way to develop the applications and the infrastructure on which these applications are hosted in the same IDE. Thus, every iteration results in a fully deployed and functional application.
AWS CDK uses constructs, which define infrastructure components with proven defaults and the flexibility to change them. The AWS Constructs library provides constructs for many AWS services that help wrap complexity and ensure 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. Importing existing CloudFormation templates into AWS CDK is also possible, 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 a 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 than CloudFormation templates. However, it synthesizes CloudFormation templates under the hood, so it adheres to the AWS cloud platform.
CDKTF is a cloud development kit from Hashicorp. Hashicorp’s IaC tool, Terraform, uses the proprietary language Hashicorp Configuration Language (HCL) and JSON. However, to develop the infrastructure, CDKTF is the preferred option, as it leverages the knowledge of familiar programming languages like Typescript, Python, Java, C#, and Go.
It is similar to AWS CDK, but we leverage Terraform’s end-to-end infrastructure lifecycle management abilities. 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. Terraform is the underlying operational layer, but you don’t have to worry about the Terraform CLI commands.
Another important CDKTF component is the cdktf package, which contains the core libraries that help convert 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 similar to AWS Constructs. Here the applications are wrapped into an app, which may contain multiple stacks, each of which is a collection of multiple cloud resources. Resources defined in stacks in the same application can communicate with each other.
CDKTF is becoming more popular because it allows developers to develop infrastructure using a familiar programming language while leveraging Terraform’s infrastructure lifecycle management capabilities.
Microsoft Bicep is an open-source domain-specific language that provides a syntax for deploying Azure resources. As a domain-specific language, it has its own set of syntax, which might add a learning curve for developers. It works with Azure Resource Manager to create and manage Azure cloud components, so it is not cloud-agnostic.
As discussed in earlier sections, ARM templates use JSON format to express the IaC, which can become cumbersome when developing large infrastructure sets. Microsoft Bicep allows for a programming experience that results in an easily traceable IaC.
Under the hood, Bicep files are submitted to ARM, which then provisions the resources on the Azure cloud.
Developing IaC using Microsoft Bicep supports modularity, allowing you to develop and reuse infrastructure components. It also implements a verification step, where you can see the operations that would be performed before actually executing them.
State management is handled by storing all state information in Azure. You can only query this information.
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 Ansible’s IaC and infrastructure lifecycle management capabilities.
Ansible works on the concept of an Ansible playbook, which is a YAML-formatted file that describes the sequence of activities that the Ansible host should perform. 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 to manage 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 provisions. There is no explicit state management with respect to the infrastructure itself and no ability to preview 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.
Before Affinity migrated to Spacelift in February 2023, the infrastructure team struggled to get Terraform to work as they wanted. Their IaC provider’s approach to representation did not map well to the way Affinity’s developers think about infrastructure and the various environments they work with, and the overall experience was frustrating. Since Affinity adopted the Spacelift platform, however, even developers who are not Terraform fans have been enthusing about the smoothness of the experience.
Alternatives to Terraform cater to a range of IaC needs. Your options 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.
Automate Terraform deployments with Spacelift
Automate your infrastructure provisioning and build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization, and many more.
Terraform CLI Commands Cheatsheet
Initialize/ plan/ apply your IaC, manage modules, state, and more.
