Recently, Terraform has gained a lot of popularity, becoming one of the standards in the infrastructure-as-code (IaC) space. Pulumi and CloudFormation are two other tools that have become well known as IaC has been adopted across the industry to make it easier for maintainers to manage and run their infrastructure across clouds. The basic principle behind IaC is that all of your infrastructure components are defined as code in a repository or any version control system.
In this article, we’re going to see how well Terraform, Pulumi, and CloudFormation are able to implement IaC principles. We’ll discuss their pros and cons, including how easy they are to use and extend.
Importance of Infrastructure as Code (IaC)
Large-scale infrastructure can be very difficult to manage, with any changes requiring you to either go to the vendor console or make some API calls. This can get out of hand very easily as your infrastructure scales. IaC solves this by abstracting the steps you have to perform to keep your infrastructure intact.
After defining the state in a code repository, an IaC tool will work in this code repository to configure the changes. You can very easily track these changes using a version control system, with commits describing all the changes made
IaC also saves you from the problem of dependency resolution, plus you don’t have to keep track of which components need to be launched and in what order.
Declarative vs. Procedural Way of Defining Infrastructure
The definition of infrastructure as code generally follows a declarative language. You have to define the state of your infrastructure, and the underlying tool will then take care of maintaining this state and keeping your infrastructure in sync.
The procedural way of defining infrastructure must mention the steps needed to reach a particular state. These are generally scripts that execute some commands and APIs to provision the infrastructure.
The advantage of a declarative definition is that you don’t have to worry about the steps taken, as the actual path is abstracted and executed behind the scenes. This means you don’t have to worry about problems like dependency resolution.
What is dependency resolution? Assume you want to create a VM. To do so, you have to launch the NIC first. With IaC, you can define the state for both the NIC and VM, and the tool will make sure to launch the NIC first and then the VM.
Infrastructure as Code (IaC) Tools
Terraform
Terraform was created and open-sourced by HashiCorp in July 2014. It follows the HashiCorp Configuration Language (HCL), which you can use to create and run resources, and is the biggest name in IaC today. Terraform works on a reconciliation model, so whenever there is drift in the defined state, it will try to sync the remote state to the defined state.
Use case: Creating a cloud-agnostic declarative system for launching resources in different clouds and making it standardized.
Pulumi
Pulumi was introduced in 2018 and open-sourced. Pulumi is unique because you can define your IaC using the language of your choice, which makes it very easy to get started with your development.
Use case: Setting up a system where you don’t want to use HCL or a domain-specific language, instead writing the IaC in a language you’re accustomed to.
CloudFormation
CloudFormation was released in 2011 by Amazon Web Services and is a very easy way to launch resources on AWS Cloud. You just have to define your configuration in YAML, and AWS CloudFormation will take care of launching the resources behind the scenes. It also follows a declarative language pattern.
Use case: Creating resources in AWS without the extra hassle of having to learn a new tool; you just define everything in YAML and your resources get launched.
The Benefits of Cloud-Agnostic Infrastructure as Code (IaC)
Generally, IaC should be able to launch resources in multiple clouds to make sure your setup works even if you move to another cloud; simply writing new scripts should allow you to create resources in a new cloud with minimal configuration changes.
While this can be done with Terraform and Pulumi, this is not the case with CloudFormation since it’s tied to AWS, meaning you can launch and configure resources only in AWS. This makes CloudFormation a less than ideal choice as your IaC tool.
Cloud-agnostic tooling is something you should consider to avoid vendor lock-in. This way, if problems arise with one vendor, you can always switch to another cloud provider.
Comparing Terraform vs. Cloudformation vs. Pulumi
- Terraform and Pulumi both have open-source and enterprise versions. You can easily install and use them both, whereas when it comes to CloudFormation, it is only available as an AWS resource, which comes with the limitations discussed above.
- Terraform uses HCL to define resources, meaning you’ll have to learn this language and use it to write the configuration. Pulumi allows you to use different languages like Python, Node.js, Golang, etc. It can, however, sometimes be hard to maintain standard practices across multiple languages if used in configuration tools like Pulumi. AWS CloudFormation, meanwhile, follows a YAML-based approach to launch and manage resources.
- Terraform and Pulumi don't have support for a UI or role-based access control, while CloudFormation has both using AWS IAM policies. A UI and RBAC can be very useful for maintaining and auditing your system. You can achieve RBAC somewhat in Terraform with a version control system. Having proper permissions on the Git repo of your code will let you audit everything and keep an eye on who is making any changes.
- Terraform and CloudFormation use the declarative way of defining resources, while in Pulumi, you will end up writing code to launch resources. You can write these in any supported programming language.
- Terraform and Pulumi both have support for integration with cloud management platforms. CloudFormation doesn’t have any such support, although you can easily manage it from the AWS console.
- Terraform has massive community adoption and is very easy to use with different extensions. Terraform also provides a way of integrating with other vendors by just writing providers for that particular cloud. Pulumi also has a way to extend support for other clouds, but it is not as great as Terraform and its community adoption is very small.
| Terraform | Pulumi | CloudFormation | |
|---|---|---|---|
| Open-source | Yes | Yes | No |
| RBAC | No | No | Yes |
| UI | No | No | Yes |
| Integration with cloud management platforms | Yes | Yes | No |
| Declarative/programming | Declarative | Programming | Declarative |
| Community adoption | Massive | Not so great | Not so great |
| Cloud-agnostic | Yes | Yes | No |
Conclusion
With the above points in mind, choosing Terraform for your infrastructure can go a long way and is easier to manage. You may have to invest some engineering hours at the start of your project to ensure a standard way of writing the code for your cloud resources, but once you have all this set up, Terraform can scale massively.
Anyone who wants to get things started faster, doesn't want to be connected to a particular cloud, and doesn’t want to invest in learning a domain-specific language for Terraform can opt for Pulumi.
CloudFormation is good if you’re already using AWS Cloud and have no plans to move away from it or span across multiple clouds in the future.
Terraform boasts a strong community, is cloud-agnostic and open-source, and uses the declarative way of defining languages, making it a good choice if you don’t have any special use case.
You may also like:
> [Video] Best Practices for Using Terraform in Your Developer Pipeline
> [Video] Pulumi vs. Cloudformation vs. Terraform
> Terraform and Ephemeral Environments with Bunnyshell
> CI/CD and Bunnyshell EaaS - Match Made in Heaven
> CI/CD and Application Release Orchestration Trend 2022 Report