Terraform isn’t as bad as you thought

Once upon a time, before you became a software engineer, you heard your colleagues mention the term "Terraform" and did your best to avoid associating it with physical terrain terraforming.

Even during your time as a front-end developer, you had no reason (or permission) to explore this intriguing technology.

Now, as a full-stack engineer, you finally have the chance to be formally introduced. But before diving into Terraform, it's essential to understand what "Infrastructure as Code" means.

Wait, Infra-what?

What is Infrastructure as Code?

Infrastructure as Code (IaC) aims to create and manage infrastructure resources through code rather than manually making changes through a UI. It can range from a single small server to an entire fleet of servers with databases and more.

You might wonder why anyone would choose to use code when you can happily modify infrastructure through a user-friendly UI. While this may work fine for small projects, it becomes an untameable beast as your infrastructure grows in size and complexity. Here are some reasons why managing complex infrastructure through a UI is not advisable:

1. Human error: There's a risk of making typos or forgetting to adjust small settings. You could double and triple-check your work and even use a checklist, but why risk it?

2. Human error: You may have the same infrastructure replicated across multiple environments like development, staging, and production, any changes must be made manually and consistently across all environments. Again, you could go slow and check yourself or even pair with someone else to check you. But why risk it?

3. Human error: Let's say you paired with other fellow engineers, used checklists and successfully made the necessary changes consistently across environments. Now, due to business requirements, you need to roll back these changes. Do you know exactly what you changed and how to undo them? Even if you documented it, you now need to trust yourself to undo these actions correctly. Why risk it?

You can define these changes in configuration files stored in version control, you can address these problems and gain additional benefits.

• Minimise the potential for human error

• Efficiently and accurately replicate configuration across environments

• Accurately roll back any changes, if necessary

• Quickly restore resources in case of incidents

This is where tools like Terraform come into play!

What is Terraform?

There are indeed many tools that enable you to write configuration files like this, they help codify the process of modifying cloud infrastructure. Terraform is one of these tools (and likely the most widely used), created by HashiCorp.

With a few simple commands on the terminal, Terraform does the heavy lifting by creating, modifying, or deleting resources according to these configuration files. It facilitates the process of automating and maintaining your cloud infrastructure consistently and efficiently.

Interestingly, Terraform's name is quite fitting, given its purpose of altering your cloud "landscape".

Photo by Anton Filatov on Unsplash

How does it work?

Configuration blocks

Well, it's all about those configuration files. Terraform uses Hashicorp Configuration Language (HCL) to create .tf files which contain configuration "blocks". It communicates with your cloud provider's API to orchestrate the instructions in these blocks with the help of providers, there's a lot of them.

Here's a basic example which creates an S3 bucket on AWS named "document-storage".

# s3.tf
resource "aws_s3_bucket" "document_storage" {
    bucket = "document-storage" 
}

We'll go over the syntax and specific properties in a separate post, this is just to illustrate the concepts a little bit.

Workflow

The main Terraform workflow consists of 3 steps:

1. Initialise

This is done both at the beginning of a project and whenever any changes are made to providers or modules. For example, if you change the version of a provider or create/amend modules.

2. Plan

Once you've made the desired changes to the configuration files, you can run a plan which essentially does a "dry run" and shows exactly what actions Terraform will perform. This gives you a chance to review the changes before making them.

3. Apply

If the planned changes look correct, you apply them and Terraform will perform the necessary actions through the provider's API to reflect any changes on your actual infrastructure.

State management

Terraform is clever enough to determine your written configuration, analyse the actual resources in your infrastructure, and decide whether to create, update, or delete resources as needed. It won't create a resource that already exists in the cloud. For instance, if you define an S3 bucket in your configuration, applying the change once will create it, and subsequent attempts with the same configuration will be ignored. Terraform will notify you that no changes are required.

Photo by Ekaterina Bolovtsova on Pexels

To keep track of all this information, Terraform utilizes a state file called terraform.tfstate. This file establishes the connection between your configuration files and the corresponding resources in the cloud. Whenever you execute an operation, Terraform automatically retrieves the current state of your resources and updates the state file. This enables comparison between your configuration (including any changes) and the actual resources in the cloud.

By default, the terraform.tfstate file is generated in the same directory as your .tf configuration files. A common mistake is including this file when uploading to version control, which should be strictly avoided. If your configuration contains sensitive resources like databases or user credentials, their unencrypted passwords will be exposed in the state file and visible to anyone accessing the version control repository.

This is why it's recommended up and down the land to use encrypted remote storage. You can either use Terraform Cloud which is Hashicorp's own solution or host it yourself with something like an S3 bucket with DynamoDB to provide locking functionality for collaboration.

Isn't it scary?

You've heard horror stories of poor souls accidentally disintegrating infrastructure. It is definitely possible but there are ways to prevent it with the right workflow if you treat it like typical application development.

1. Code review

You wouldn't introduce a new feature to an application or refactor critical logic without getting your changes peer-reviewed. This should happen before you even think about applying your changes, even if you're only changing development or staging configuration.

2. QA your changes

Again, you wouldn't introduce a new feature by releasing it to production without testing it first on development and staging environments. This gives you several opportunities to spot any accidental deletions before you go anywhere near production.

3. Revert

If the above somehow doesn't catch a mistake and faulty changes are applied to production, you can roll back. Your configuration files are version controlled and you can revert to the previous working configuration and apply those changes. Any irreversible damage such as wiping a database can be fixed by restoring a backup. If there are no backups, that's a whole different issue in itself and shouldn't be a reason to avoid Infrastructure as Code. Please create backups.

Conclusion

While the concept of Terraform and IaC, in general, may sound intimidating, it provides a lot of benefits that outweigh its risks. The alternative human-driven approach is also prone to accidentally nuking important infrastructure and it's definitely a very real scenario...

If both approaches have this similar risk, why go for the human-driven approach that doesn't guarantee accuracy, consistency and speed?

That's enough conceptual information, let's take a look at how all of this comes together in practice!