How I Learned to Love Terraform (And Why You Should Too)

When I started to learn about AWS, I started by tinkering around in the AWS Management Console. I thought how cool it was that I could enable and deploy services with a simple set of presses of buttons and all the options that it offered. But as I continued my cloud journey, I realized how onerous it can be to figure out all the settings and make sure that they’re the same for all the services you want to use. This is especially important if an error happens and you don’t know what’s happening. It can take forever to properly fix the issue and deploy what’s needed.

I knew I needed a fast way, and that’s when I learned about Terraform. Terraform has been a game-changer for me with regards to deploying my infrastructure. No longer do I have to log in, deal with passwords and MFA, and all the buttons I could want if I want to make changes. Now I can simply edit a few files, run a few commands, and voila! Everything’s done for me by Terraform, and all I have to do is check to make sure I didn’t mess up.

In this article, I will explore the various ways you can use Terraform and how to use it for your own use.

What is Terraform?

Before we delve into the specifics of Terraform, we should probably discuss what Terraform is. Terraform is an Infrastructure as Code service, which means that you use maintainable templates rather than using consoles. This automates deployment, reduces errors, and makes it easier to copy settings over to other services as you need them.

This differs from ClickOps, which is the act of pressing lots of buttons on a console. This can be good for a quick one-off or when you’re first starting out learning cloud technology. However, there are various drawbacks to ClickOps that Terraform covers:

• It’s invisible: You don’t actually know what you did and if you want to go back and see what you did, it’s impossible to do so. Terraform contains a history of what you did as well as the plan in specific concrete Terraform files so you can go back and see what happened.

• It’s fragile: One wrong button is pressed in ClickOps and everything goes haywire, while in Terraform the console warns you what the changes will be and then presents you with the appropriate error if it’s unable to make the change. It’s simple to avoid critical mistakes with Terraform.

• It’s unrepeatable. If you want to set up the same infrastructure either for yourself if you’re migrating to another computer or for someone else getting ready to start diving into your infrastructure, it can be impossible to remember the exact steps that you took, and digging through all the present configurations can be annoying. With terraform, you don’t even have to list what the infrastructure is. Just let Terraform do the work for you and you’re all set, with little to no input needed from the customer.

• It’s not scalable. Imagine trying to do the ClickOps for 10, let alone 100 computers. 1 is bad enough; it would become extremely time-consuming for bigger amounts of systems. Terraform, however, makes it extremely easy to scale with how simple it is to adjust infrastructure.

Example of Terraform

Here is a simple example of Terraform that shows how simple configuring infrastructure can be.

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name        = "AppServer"
    Environment = "staging"
  }
}

Notice how easy it is to list specific settings as you want it while also being organized with your setup. You can introduce variables through the variables.tf file and outputs with the outputs.tf file. You can set up required providers through terraform.tf and list the main chunk of your configuration in main.tf.

The only steps you have to do once you make the files listed above is

terraform init
terraform plan
terraform apply

That’s it! There are other features if needed, but it’s purely optional.

Benefits

• You can see the Plan before you Apply

One big benefit of terraform is that you can see the changes and how they would be applied before you apply them. Here is an example of what you might see when you do “terraform plan”:

# aws_security_group.app will be created 
+ resource "aws_security_group" "app" { 
    + name = "app-sg" 
    + description = "App security group" 
    + ingress { 
          + from_port = 443 
          + to_port = 443 
          + protocol = "tcp" 
          + cidr_blocks = ["0.0.0.0/0"] 
     } 
}

Here you can see that the aws_security_group app resource will be created along with the specific settings for that security group. This also goes for any resources that need to be deleted and then replaced as well as any that are just plain deleted. This gives you the option to make sure the changes that you wanted to have done are actually done before you do “terraform apply”

• You can make nearly anything

There are a wide variety of AWS services that you can create through Terraform, including S3, DynamoDB, IAM roles, IAM policies, CloudFront distributions, and more. You can even make cloud technologies other than AWS, like Azure and GCS, and you can create cloud-adjacent technologies like CloudFlare, which is used to help protect websites created through CloudFront distributions.

• Repeatable configurations

Terraform is great for when you have a number of different environments that all need to maintain the same settings for a long period of time, even as you deploy the rest of the services. Terraform keeps whatever values don’t change intact for as long as you need it to, which increases compatibility and decreases time to deploy. Take for instance dev, staging, and prod environments that all need the same VPC settings, security group rules, and IAM policies. If you used the console, you would have to go to each place and set them yourself, hoping along the way you didn’t encounter a brainfart and forget the settings. Then if something bad happened, you would have to trace your steps and hope that the correct settings come back to you. With Terraform, that’s not an issue. You can keep the configurations the same across multiple environments and if one is slightly off, Terraform will let you know before it gets deployed.

One concept of Terraform that builds on that idea is Terraform modules. Modules are a way to reuse configurable settings across multiple environments without having to list them out every time. Think of Terraform modules as fancy variables/objects. Variables and objects in OOP can be used to store data so you don’t have to list them out yourself every time. Modules provide the same thinking but with infrastructure configuration instead.

Here’s an example of a Terraform module:

module "web_app" { 
    source = "./modules/web-app" 
    name = "my-service" 
    environment = "production" 
    instance_type = "t3.medium" 
}

• State Management

Terraform can compare your current configuration and what changes you want to make and see if anything needs to be changed. This means Terraform won’t recreate resources that already exist - it only acts on what’s actually changed. This is because Terraform tracks what it’s done in a .tfstate file. This also allows you to go back and see what changes were made and you can show other people so they can understand the evolution of the infrastructure. You can also store these changes remotely or in version control. This is also what makes those repeatable configurations reliable over time.

I encourage you to try out Terraform for yourself and see how it can assist you in your tasks. If you want to get started, check out the Terraform tutorials at https://developer.hashicorp.com/terraform/tutorials and make a simple resource like an AWS S3 bucket to see the changes for yourself. I’d also be interested to hear stories from anyone else who have found Terraform to be a lifesaver - drop them in the comments below.