So you might have heard of this Terraform thing, but you’re not totally sure what it is, right? Not to fear, we’ve got you covered…
Today we’re going to dive into what Terraform is, why it’s useful, how it compares to other tools, and some of the difficulties of using it.
By the end of this article you’ll understand what Terraform is, why it’s useful and what you’d use it for.
Terraform is an open source, CLI-based infrastructure as code tool created by Hashicorp. Terraform is cloud agnostic and works across all major cloud providers: AWS, GCP and Azure. Not to be confused with Terraform Cloud, which is Hashicorp’s paid hosted solution for Terraform.
Terraform uses “providers” to integrate with different services. Many providers already exist for the central use cases of Terraform (typically cloud applications). Terraform also has some lesser known providers that allow other popular vendors such as Stripe and Auth0 to be managed in Terraform.
To understand why Terraform is useful, we need to understand principles of infrastructure as code. Infrastructure as code is too large of a topic to cover in this article alone. So let’s do a super quick whirlwind tour…
Let's start with the anti-thesis to infrastructure as code: manually creating and updating your infrastructure. When infrastructure is created manually, knowledge ends up trapped in the heads of individuals and future updates are scary, unrepeatable, difficult and undocumented.
But that’s where infrastructure as code can help. By storing infrastructure configurations in code, and not making changes manually, engineers can apply processes, such as code review to their infrastructure changes too. The code acts as documentation, and becomes a history of changes.
Terraform is tool to help implement of infrastructure as code, and therefore the benefits of Terraform are somewhat synonymous. With Terraform you can store configurations in version control, you can apply changes safely and in a repeatable way.
For more on infrastructure as code, check out: Infrastructure As Code: An Ultimate Guide
So we’ve discussed the benefits of Terraform, but how does it actually work? What does working with Terraform look like? Let’s look at that now…
Terraform works by writing resource configurations in HCL (Terraform’s language). These resource blocks are determined by the provider but they all conform to the same patterns and structure.
When the configuration is written, the engineer will exeucte a Terraform plan command. A Terraform plan is essentially a dry run that shows the changes that would be made if the changes were truly applied.
Once the engineer is happy with the changes, they run a Terraform apply command to commit changes. Terraform apply then triggers the underlying provider and starts to create, update or delete infrastructure resources.
Okay, so far our descriptions have been abstract. To make things more concrete let’s look at some real examples of things that you can build with Terraform, and how that looks in reality.
Deploying a website on AWS — Terraform can be used to create cloud resources such as basic (or complex) websites on AWS. You can do this by creating an S3 bucket with Terraform like so…
Creating network infrastructure on GCP — Terraform can be used to create core infrastructure on GCP. Terraform can then be used to create additional applications or services on this core platform. You can do do this by using the GCP provider to create the required networking components like so…
Creating Heroku environments — Terraform can be used to create on-demand environments in Heroku. You can do this through the Heroku provider like so…
There are many different infrastructure as code tools that exist. So naturally you might be wondering how Terraform compares and when you should use each? Let’s take a quick look at how Terraform compares to both cloud provided alternatives and configuration management tools.
Most of the big cloud providers have their own infrastructure as code tool. In AWS that’s CloudFormation. At first glance CloudFormation can seem very similar to Terraform. So what makes them different?
Firstly, Terraform differs by being open source and cloud agnostic. Due to the fact Terraform is not tied to any given provider means that Terraform technology and skills can be used across many different platforms and multiple tools are not required and skills do not have to be learned.
A second big difference is in Terraforms features (notably the language Terraform is written in HCL) which can be considered quite proprietary and supported by a large and enthusiastic open source community.
Tools such as Chef, Puppet and Ansible are used mainly for configuration management (typically applied to already existing infrastructure). Whereas Terraform is designed to create, editing and destroy resources.
That said, Terraform can be used alongside the configuration management tools quite well. For instance Terraform can install configuration management tools on resources so that the tools can be used in tandem.
Hopefully by now you have a better understanding of what Terraform is. However, I am conscious I might not be giving you the full picture if we don’t also discuss the difficulties in using Terraform. Let’s cover that now…
Terraform is CLI-based which means that in order to run Terraform you must execute commands either on your own machine or server. But managing commands can be difficult, notably if a command fails part-way through execution, this can put Terraform into an unknown state, which can be a pain to debug and undo.
In comparison, managed services like CloudFormation don’t suffer the same execution problem. But why? Because CloudFormation commands are ran on hosted services (not on your machine). Which means, by running on hosted services, managed services ensure availability and fault-tolerance that Terraform (the CLI) cannot assure.
Terraform works by maintaining a state file. The state file is updated when any command is executed that changes provisioned resources. The state file helps Terraform understand dependencies and connect real world infrastructure.
But setting up the state file can be fiddly. If you store the state file in version control, you risk exposing secrets and creating a security vulnerability.
There is a solution, however, to how and where you should store Terraform state files, and that’s by using the Terraform feature of backends, the problem is that setting up a backend isn’t a totally straight-forward endeavour.
In fact, setting up backends isn’t that bad (when you’re used to it) but it does present a hurdle to those new to Terraform. Lack of understanding usually leads to mistakes, which in this case could be some painful security issues.
For more details on Terraform state files and their management, check out: Should You Commit the Terraform .tfstate File to Git?
And that concludes our look at Terraform. Hopefully now you now have a better idea of what Terraform is and why you might consider using it.
The best way to evaluate a tool is by getting your hands on it. So I suggest experimenting with Terraform as the next step of your investigation.
Speak soon Cloud Native friends!
Lou is the editor of The Cloud Native Software Engineering Newsletter a Newsletter dedicated to making Cloud Software Engineering more accessible and easy to understand. Every month you’ll get a digest of the best content for Cloud Native Software Engineers right in your inbox.