Managing Infrastructure As Code: Terraform Explained

When you search for the term “infrastructure-as-code” (or IaC), you’ll quickly find a list of the most popular IaC tools out there:

Chef

Puppet

Ansible

Pulumi

CloudFormation

Terraform

Heat

And while each tool has its own benefits, the difficult part is determining which one to use.

All of these tools are capable of managing infrastructure as code, in addition to sharing other commonalities:

• They are all open-source, have large contributor communities, and work with various cloud providers (except for CloudFormation, which is closed-source and AWS-only).
• They all provide enterprise support.
• They are all well-documented in both official documentation and community resources like blog posts and StackOverflow questions.

So, how do you make a decision?

For us, we do have a top pick: Terraform.

In this article, while we will talk about all of these IaC tools, we’ll also find how Terraform compares with the rest and reveal why we prefer it over others.

Terraform vs Others

There’s another challenge when choosing the best IaC tool.

Most online comparisons between these tools do little more than list the general properties of each tool, making it sound like you could be equally successful with any of them.

While technically correct, this is not helpful; it’s a little like telling a programming newbie that you could build a website just as well with PHP, C, or Assembly — a technically correct statement, but one that leaves out a lot of information that would be extremely helpful in making a good decision.

In this article, we’ll go over the specific reasons why Terraform is our top pick over other IaC tools.

Why Terraform: The Trade-Offs

As with all technological decisions, it comes down to trade-offs and priorities.

And while your priorities may differ from ours, we hope that sharing our thought process will assist you in making your own decision.

The following are the main trade-offs we considered:

• Configuration Management vs Provisioning
• Mutable Infrastructure vs Immutable Infrastructure
• Procedural vs Declarative
• General-purpose Language vs Domain-specific Language
• Master vs Masterless
• Agent vs Agentless
• Paid vs Free Offering
• Large Community vs Small Community
• Mature vs Cutting Edge
• Using Multiple Tools Together

Configuration Management vs Provisioning

Chef, Puppet, and Ansible are all configuration management tools, meaning they are intended to deploy and manage software on existing servers.

CloudFormation, Heat, Pulumi, and Terraform are provisioning tools, which means they are meant to supply servers (along with the rest of your infrastructure, such as load balancers, databases, networking setup, and so on), leaving the chore of configuring those servers to other tools.

But, if you are not utilizing server templating tools, a configuration management and provisioning solution combined is an excellent option.

For example, using Terraform to provide your servers and Ansible to set up each one is a popular combo.

Mutable Infrastructure vs Immutable Infrastructure

Mutable infrastructures allow regular updates and changes after the software is deployed, while immutable infrastructures do not allow changes after the software is deployed.

Procedural vs Declarative

Chef and Ansible support a procedural approach in which you write code that explains how to attain a desired end state step by step.

Terraform, CloudFormation, Pulumi, Heat, and Puppet all support a more declarative approach, in which you write code that defines your intended end state, and the IaC tool determines how to attain that state.

General-purpose Language vs Domain-specific Language

Chef and Pulumi enable you to manage infrastructure like code by using a general-purpose programming language (GPL): Pulumi supports a broad range of GPLs, including JavaScript, TypeScript, Python, Go, C#, Java, and others, whereas Chef supports Ruby.

To manage infrastructure as code, Terraform, Puppet, Ansible, CloudFormation, and OpenStack Heat all employ a domain-specific language (DSL): Terraform makes use of HCL; Puppet makes use of Puppet Language; and Ansible, CloudFormation, and OpenStack Heat make use of YAML (CloudFormation also supports JSON).

DSLs have some benefits over GPLs:

• That is simpler to learn
• More concise and clear
• Greater consistency

GPLs offer some benefits over DSLs as well:

• Sometimes there is no need to learn anything new
• More sophisticated toolset and a larger ecosystem
• Greater strength

Master vs Masterless

Chef and Puppet, by default, require you to maintain a master server for preserving the state of your infrastructure and distributing changes.

By default, Ansible, CloudFormation, Heat, Terraform, and Pulumi are all masterless.

To be more specific, some of them rely on a master server, but it’s already a part of the infrastructure you’re utilizing and not an extra component you have to maintain.

For example, Terraform interfaces with cloud providers via their APIs; therefore, the API servers are similar to master servers in certain ways, except that they don’t require any additional infrastructure or authentication processes.

Agent vs Agentless

Chef and Puppet require the installation of agent software (e.g., Chef Client, Puppet Agent) on each server to be configured.

There are some challenges that come with this:

• Bootstrapping
• Maintenance
• Security

Ansible, CloudFormation, Heat, Terraform, and Pulumi do not require any additional agents to be installed.

To be more specific, some of them necessitate the use of agents, which are often already deployed as part of the infrastructure you’re utilizing. Amazon, Azure, Google Cloud, and all other cloud providers, for example, install, manage, and authenticate agent software on each of their physical servers.

You don’t have to worry about any of that as a Terraform user: you simply give instructions, and the cloud provider’s agents execute them on all of your servers.

Ansible requires that your servers execute the SSH daemon, which is standard on most servers.

Paid vs Free Offering

CloudFormation and OpenStack Heat are absolutely free: the resources you deploy with those tools may be expensive, but you don’t have to pay anything to utilize them.

Terraform, Chef, Puppet, Ansible, and Pulumi all have free and commercial versions: for example, you may use Terraform’s free and open-source version by itself, or you can combine it with HashiCorp’s premium product, Terraform Cloud.

Large Community vs Small Community

When you select a technology, you are also selecting a community. It’s tough to make an exact comparison between localities.

The table below compares popular IaC tools based on data I gathered in June 2022, including whether the IaC tool is open source or closed source, what cloud providers it supports, the total number of contributors and stars on GitHub, how many open source libraries are available for the tool, and the number of Stack Overflow questions listed for that tool.

(Note: The data on contributors and stars comes from the open source repositories for each tool, but as CloudFormation is closed source, this information is unavailable).

Mature vs Cutting Edge

Another vital thing to consider when selecting a technology is maturity.

The table below displays the first release dates, current version numbers (as of June 2022), and my subjective assessment of each IaC tool’s maturity.

Pulumi is the most recent IaC tool in some comparisons and, arguably, the least mature: this becomes clear when searching for documentation, best practices, community modules, and so on.

Terraform is a bit more mature these days: the tooling has improved, best practices are better understood, there are far more learning resources available, and it is a far more stable and reliable tool now that it has reached the 1.0.0 milestone than it was when the first and second editions of Terraform: Up & Running were released.

Chef and Puppet are the most mature and oldest tools.

Using Multiple Tools Together

Despite the fact that I’ve been comparing IaC tools throughout this article, the reality is that you’ll most likely need to use a combination of tools to build your infrastructure.

The sections that follow show three common combinations that I’ve seen work well at a variety of companies.

1. Provisioning plus configuration management
2. Provisioning plus server templating
3. Provisioning plus server templating plus orchestration

Provisioning plus configuration management

As an example, consider Terraform and Ansible.

Terraform deploys all underlying infrastructure, such as network topology (e.g., virtual private clouds, subnets, route tables), data stores (e.g., MySQL, Redis), load balancers, and servers.

You then use Ansible to deploy your apps on top of those servers.

This is a simple strategy to begin with because no additional infrastructure is required (Terraform and Ansible are both client-only programmes), and there are several ways to enable Ansible and Terraform to operate together.

Provisioning plus server templating

Terraform and Packer are two examples.

Packer is used to package your apps as VM images.

Terraform is then used to deploy servers with these VM images, as well as the rest of your infrastructure, such as network topology (i.e., VPCs, subnets, route tables), data stores (e.g., MySQL, Redis), and load balancers.

This is also a simple technique to begin with because no additional infrastructure is required (Terraform and Packer are both client-only programmes).

Furthermore, because this is an immutable infrastructure solution, maintenance is simplified.

Provisioning plus server templating plus orchestration

Terraform, Packer, Docker, and Kubernetes are a few examples. Packer is used to produce a VM image that includes Docker and Kubernetes agents.

Terraform is then used to deploy a cluster of servers, each of which runs this VM image as well as the rest of your infrastructure, such as the network topology (i.e., VPCs, subnets, route tables), data stores (e.g., MySQL, Redis), and load balancers.

Finally, when the server cluster powers up, a Kubernetes cluster is formed, which you can use to execute and manage your Dockerized apps.

The benefit of this strategy is that Docker images develop rapidly, you can run and test them on your local computer, and you can use all of Kubernetes’ built-in capabilities, such as multiple deployment strategies, auto-healing, auto-scaling, and so on.

The disadvantage is the added complexity, both in terms of extra infrastructure to run (Kubernetes clusters are difficult and expensive to deploy and operate, though most major cloud providers now provide managed Kubernetes services, which can offload some of this work) and several extra layers of abstraction to learn, manage, and debug (Kubernetes, Docker, Packer).

Final Takeaway

Considering everything, the table below compares the most popular IaC tools, depicting the most common or default configuration of the various tools.

However, it’s important to note that, as discussed earlier, these IaC tools are flexible enough to be used in other configurations as well (e.g., you can use Chef without a master, you can use Puppet to do immutable infrastructure, etc.).

Want more expert insights into what an ideal DevOps culture looks like and how it can help? Check out this article: 6 Reasons Why You Should Adopt a DevOps Culture in Your Business