DEV Community

ontrack
ontrack

Posted on

The Terraform Advantage

The Terraform Advantage: Infrastructure That Can Explain Itself

Why I think Terraform is more than an infrastructure deployment tool.

When I first started working with Terraform, I thought its main advantage was simple:

It creates cloud infrastructure without making me click through the AWS console.

That's useful.

But the more I use it, the more I think that's actually one of the least interesting things about Terraform.

The real advantage is that Terraform gives infrastructure something that manual infrastructure often doesn't have:

A clear explanation of what should exist, why it exists, and what will change before the change happens.


The problem with clicking everything

Imagine creating an AWS environment manually.

You create a VPC.

Then subnets.

Then route tables.

Then security groups.

Then EC2 instances.

Then IAM roles.

Then load balancers.

A few weeks later, someone asks:

"Why does this security group allow that traffic?"

You might have to search through the AWS console and try to remember.

With Terraform, the answer can be sitting in a .tf file.

For example:

resource "aws_security_group" "web" {
  name = "web-server"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }
}
Enter fullscreen mode Exit fullscreen mode

The configuration isn't just instructions.

It's documentation that can actually create the infrastructure.

That's a powerful difference.


Terraform makes infrastructure reviewable

One of my favorite Terraform commands is:

terraform plan
Enter fullscreen mode Exit fullscreen mode

Before changing infrastructure, Terraform shows what it intends to do.

That changes the workflow completely.

Instead of:

"I think this change is safe."
Enter fullscreen mode Exit fullscreen mode

You can have:

"Here is exactly what Terraform wants to change."
Enter fullscreen mode Exit fullscreen mode

For example:

Plan: 2 to add, 1 to change, 0 to destroy.
Enter fullscreen mode Exit fullscreen mode

That gives engineers an opportunity to stop and ask:

"Why is Terraform destroying this resource?"

That question can prevent a very bad production deployment.


Infrastructure becomes part of the codebase

This is where Terraform becomes especially useful.

Your application has:

Git
Pull requests
Code review
CI/CD
Tests
History
Enter fullscreen mode Exit fullscreen mode

Why shouldn't infrastructure have the same treatment?

With Terraform, infrastructure can live alongside the same engineering workflow.

A change can look like:

Developer
    ↓
Change Terraform
    ↓
Git commit
    ↓
Pull request
    ↓
terraform plan
    ↓
Review
    ↓
Apply
    ↓
Infrastructure
Enter fullscreen mode Exit fullscreen mode

Now infrastructure changes aren't mysterious console actions.

They are changes that can be reviewed.


The same infrastructure can be recreated

Another reason I prefer Terraform is repeatability.

Imagine you manually build a development environment.

Then someone asks:

"Can we create the same environment for testing?"

With manual infrastructure, you have to remember what you created.

With Terraform, the configuration already describes it.

You can use variables for different environments:

environment = "development"
Enter fullscreen mode Exit fullscreen mode

or:

environment = "production"
Enter fullscreen mode Exit fullscreen mode

The architecture can remain consistent while the values change.

This makes Terraform especially useful when you need development, staging, and production environments that follow the same design.


Terraform doesn't care only about one cloud

Another major advantage is that Terraform isn't limited to one infrastructure platform.

A single Terraform workflow can manage resources across different providers.

For example:

AWS
Azure
Kubernetes
GitHub
Cloudflare
DNS providers
Enter fullscreen mode Exit fullscreen mode

That doesn't mean every organization needs multi-cloud infrastructure.

It means you don't necessarily need a completely different infrastructure workflow every time another platform enters the environment.

Terraform's provider model is one of the reasons it can manage both cloud and non-cloud services through a common configuration approach.


Modules turn infrastructure into building blocks

Terraform also becomes much more interesting when you start using modules.

Instead of repeatedly writing the same infrastructure:

VPC
Subnets
Security Groups
IAM
Load Balancer
Enter fullscreen mode Exit fullscreen mode

you can package a common architecture into a module.

Then another project can reuse it.

For example:

module "network" {
  source = "./modules/network"

  environment = "production"
  cidr_block  = "10.0.0.0/16"
}
Enter fullscreen mode Exit fullscreen mode

Now infrastructure can be treated like a reusable software component.

That can dramatically reduce duplication.


Terraform doesn't eliminate mistakes

This is important.

Terraform isn't magic.

You can still write bad Terraform.

You can still destroy the wrong resource.

You can still create overly permissive security groups.

You can still lose control of your state.

Terraform simply gives you better tools for managing those risks.

That's why I don't think the real question is:

"Can Terraform make infrastructure perfect?"

It can't.

The better question is:

"Can Terraform make infrastructure easier to understand, review, reproduce, and control?"

For me, the answer is yes.


The part I value most

If I had to choose one reason to use Terraform, it wouldn't be multi-cloud.

It wouldn't even be automation.

It would be visibility.

When infrastructure is written as code, I can open the repository and start understanding the environment.

I can see:

What exists
What depends on what
Which resources belong together
What changed
Who changed it
What Terraform plans to do next
Enter fullscreen mode Exit fullscreen mode

That is difficult to achieve with infrastructure that exists only through console clicks.


Terraform changes the mindset

The biggest change isn't technical.

It's mental.

Without infrastructure as code, the mindset can become:

"How do I create this server?"
Enter fullscreen mode Exit fullscreen mode

With Terraform, it becomes:

"What should the infrastructure look like?"
Enter fullscreen mode Exit fullscreen mode

That is a much better question.

You stop thinking only about individual servers and start thinking about the entire desired environment.

For example:

Network
   ↓
Security
   ↓
Compute
   ↓
Storage
   ↓
Application
   ↓
Monitoring
Enter fullscreen mode Exit fullscreen mode

Terraform can represent those relationships as code.


So, is Terraform the best?

I don't think there is one infrastructure tool that is objectively the best for every organization.

CloudFormation can make sense for AWS-focused teams.

Pulumi can be attractive if you want to use general-purpose programming languages.

OpenTofu is another important option in the Terraform ecosystem.

The right tool depends on the environment, team, requirements, and existing workflows.

But Terraform remains my preferred choice when I want infrastructure that is:

Declarative
Repeatable
Reviewable
Version-controlled
Reusable
Provider-independent
Enter fullscreen mode Exit fullscreen mode

And that's why I keep coming back to it.

Terraform isn't just a way to create infrastructure.

It gives infrastructure a language.

And once infrastructure can be expressed as code, it becomes much easier to review, improve, reproduce, and understand.

That's the real Terraform advantage.

thanks ontrack

Top comments (0)