Infrastructure as code with Terraform

A decade ago, deploying a new database meant logging into AWS Console, clicking through forms, and manually recording what you'd created somewhere (maybe a wiki, maybe a ticket, maybe just hope). Every change you made was another manual step; every mistake lived in your live system and in someone's memory of what they'd clicked. Infrastructure as code reverses this: you declare resources (a database, a server, a queue) as text files, check those files into git like your application code, and a tool like Terraform applies those declarations to your cloud provider.

This gives you:

A Terraform file (with a .tf extension) contains three main kinds of declarations:

Resources — the actual things you want to create:

This declares an S3 bucket. The resource type (aws_s3_bucket) tells Terraform what provider (AWS) and what thing to create. The local name (documents) lets other parts of your .tf files refer to this bucket. The bucket argument specifies its actual name.

Variables — inputs you can change without editing the .tf file:

Variables let you parameterize your infrastructure — same code, different var.environment for dev vs. prod, and pass different values via command-line flags or files.

Outputs — values you want to know after Terraform applies:

Once Terraform finishes creating resources, it prints (or saves to a file) the outputs — often the URLs or names your application code needs. Instead of clicking AWS Console to find the database hostname, Terraform gives it to you directly.

Terraform maintains a state file — a JSON record of every resource it created and its current properties. When you run terraform apply a second time, Terraform compares your .tf files against the state file: "Did I create this bucket before? Is it still there? Have the properties changed?" This is how it knows what to update, delete, or leave alone.

State files must be stored carefully — typically in S3 or a Terraform Cloud backend, not committed to git, because they can contain sensitive values (database passwords, API keys). A typical setup:

This tells Terraform to store state remotely in S3, not locally, so multiple people on a team apply changes against the same state file.

When something goes wrong (a typo in a resource name, a invalid configuration), terraform plan catches it before anything breaks in production.

Without infrastructure as code, your infrastructure is invisible — living only in the cloud console and the brains of whoever set it up. With Terraform, infrastructure is a first-class citizen alongside your application code, reviewed in PRs, versioned in git, and reproducible from a single directory. A new team member can run terraform apply and get an identical staging environment without ever clicking a console.