Terraform Certification (Part 3): The Terraform Landscape

How does Terraform compare to other Infrastructure as Code (IaC) tools? What makes Terraform unique? Why would you pick Terraform ahead of Azure Bicep or AWS CloudFormation?

In this lesson we will touch on the following topics of the exam curriculum:

This lesson will be mostly theoretical, we will not see any HCL or terraform CLI commands. We save that for the next lesson!

Infrastructure as Code

To start off, wouldn't it be a good idea to define Infrastructure as Code (IaC) properly? Since we are learning Terraform and we want to become Terraform Associate Certified, then it would be a good idea to focus on what Hashicorp thinks IaC is? I think so. The following snippet from the official documentation explains IaC in terms of Terraform:

HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features.

A few important points to highlight that is common for most IaC tools:

• IaC usually consists of human-readable configuration files. In the case of Terraform this means files written in the Hashicorp Configuration Language (HCL). IaC is mostly, despite the name, not code in the traditional sense. It is usually configuration.
• When you work with IaC you use a consistent workflow to provision and manage all of your infrastructure. This means that we are not clicking in a web portal to create a few resources, using custom scripts for others, and Terraform for the rest. At least that is not the idea. The idea is to use one tool (Terraform in this case) to set up all your resources, whatever they are and wherever they need to be.

Other benefits of IaC, in combination with keeping your IaC in source control, include:

• Gain an audit log of all the changes that happens in your infrastructure. Why did we delete a subnet in our AWS VPC? Who added an additional compute node in our Kubernetes cluster? These questions are not difficult to answer when all changes happens though IaC via our source control repository.
• Have an accurate documentation of what infrastructure you currently have. If you use manual processes to set up your infrastructure you better hope you document everything along the way otherwise you will miss something. If you use IaC you have the documentation right in your source control repository, in the form of HCL in the case of Terraform.
• Gain confidence in your infrastructure changes. Terraform can help you by telling you what changes it will perform when you update your configuration. This could be difficult to predict when you make manual changes though a GUI or a custom script.
• Collaborate on your infrastructure. If you have all your HCL making up your infrastructure in your source code repository you can collaborate on it with your colleagues. It would be a nightmare if everyone sat in the same GUI making various changes with no visibility.
• Be able to spin up replica environments for testing and development. If you have defined all the resources needed for your environment in HCL, you can use Terraform to create replicas of it whenever you need one, and then just deleted it when you are done.

There are other benefits too, maybe you can think of some? But the ones listed here are some of the most beneficial ones that I have encountered.

Terraform versus other tools

So what makes Terraform unique in the land of IaC?

This question had an obvious answer a few years ago, but to me it is not that clear anymore. What was the answer a few years ago? That Terraform was a cloud-agnostic tool that could work with any API. You could have a Terraform configuration file that created resources in AWS, Azure, GCP, your Kubernetes cluster, Alibaba Cloud, plus created local files on your laptop and at the same time. This is still one of the major benefits that the certification exam will accept as a valid answer. Note that nowadays there are other tools that can do this as well, that is why I say the unique benefits of Terraform is no longer obvious.

So, Terraform can work with any API¹, be it a cloud provider or anything else. There is another strong point hidden in that sentence that makes Terraform a useful tool. Terraform can work in both the control plane and the data plane. The control plane is usually where we talk about creating resources (virtual machines, databases, virtual networks, etc) and configuring them to suit our needs. The data plane is where our data is stored, the rows in our database, the source code of our Azure Functions, etc. Traditionally IaC tools were only concerned with the control plane. Since Terraform can work with any API it can do whatever the API can do, and the full data plane is usually available to Terraform. If we look back at the definition of IaC I cited above Hashicorp refers to the control plane as low-level and the data plane as high-level.

In reality this also depends on what is offered through Terraform providers. Terraform itself is limited to the limitations of its providers. A provider is basically an interface to a specific API. Hashicorp is involved in creating many of the providers themselves, so these providers are usually high-quality providers. For instance, the best provider on the market is the AWS-provider. If you are using AWS and you are thinking about using Terraform but you are not sure if it is a good fit, I can assure you that there is no better fit. Ff your plan is to use only AWS, and you are wondering if you should use Terraform or the AWS-native tool called CloudFormation, what should you pick? A few years ago I would have said CloudFormation without hesitation. Today the answer is less obvious because the AWS-provider for Terraform has been improved a lot. Today there is even 0-day wait for new resource types, i.e. when AWS releases a new resource type you will be able to use it almost immediately in your Terraform configurations. Today I might instead say that you should pick Terraform ahead of CloudFormation. One drawback with CloudFormation is that it is YAML-based and there are not many intrinsic functions and other "programming language features" that Terraform has.

Apart from the official Hashicorp-produced providers there are thousands of unofficial providers for various APIs. You can even write your own providers for your own API. This could be a good idea if you work at a company where you have a public API and you want to provide a way for your customers to automate the usage of your API. Writing a custom provider for an API is not part of the Terraform Associate Certification, so we won't go into that in this course.

Summary

This theoretical lesson contained a lot of information about IaC and Terraform. It covered part 1 and most of part 2 of the exam curriculum. Some of the main points to remember from this lesson are:

• IaC means writing human-readable configuration files that define your resources (virtual machines, databases, networks, etc)
• IaC is a good practice that allows you to standardize how you apply changes to your infrastructure and how you collaborate on your infrastructure with your colleagues
• Terraform is considered to be a multi-cloud IaC tool, but it can work with any API, not just the big cloud providers
• Terraform can do more than traditional IaC tools because its operations span both the control plane and the data plane
• Selecting between Terraform and another IaC tool usually comes down to:
  • Do you need to work with more than one cloud or product? If yes: Terraform is a better choice.
  • Do you need benefits that the HCL language can provide that is not available in the other tool (e.g. if it is YAML-based)? If yes: select Terraform.

1. I say any API, and that is mostly true! The API should follow a CRUD-style (Create, Read, Update, Delete). ↩