Why Do We Need Terraform?

Audience

beginner, no prerequisites

Duration

20 to 30 min

Module

1/7

Skill

explain what Terraform does that a console, a script or a procedure does not do, and use the right term (desired state, state, provider, drift) to say it

Who uses this, and why

When you open Slack in the morning, the servers answering you were not created by hand in a console. They were described in text files, reviewed in a merge request, then built by Terraform. Same at GitHub, at Decathlon, and in thousands of smaller teams. Here are four public facts, verifiable, with their source.

What these teams have in common: they always have a cloud console, and they use it to look. But the source of truth, what says what must exist, is the code. Nobody creates a server by clicking. That is exactly what you will do in this course, on a small scale: first a text file on your machine, then an S3 bucket, then four platforms at once.

The definitions

Six words will come back in every lesson. They are given here with the definition HashiCorp gives them, and the link to the official page.

In one picture

Imagine an architect in charge of a building. He has three things at hand.

• The blueprint: the signed drawings that say what the building should be. In Terraform, these are your .tf files.
• The real building: what is constructed, with its flaws, its walls moved by an overzealous worker, its door added without notice. In Terraform, this is your AWS account, your GitHub organization, your hard drive.
• The record: the notebook where the architect noted, room by room, what he had built and under what number. In Terraform, this is the state.

Each time he is asked to intervene, the architect does the same thing. He rereads the blueprint. He opens his record. He goes to see the building. Then he compares all three and writes a work estimate: this wall is missing, build it; this door is not on the blueprint, remove it; this window is in the right place, leave it alone. The estimate is signed by the client, and only then do the trades (the providers) execute each line. Nothing more, nothing less than the estimate.

This image comes back throughout the course. When a lesson talks about the blueprint, the record and the building, it is talking about the code, the state and the real infrastructure.

The key difference between "the blueprint" and terraform plan. In the image, the blueprint is the architect's drawing, that is, your code. The command terraform plan, on the other hand, produces the work estimate: the list of what will change for the building to match the blueprint. Two meanings for the same word. In the course, we write "the blueprint (the code)" or "the estimate (the output of terraform plan)" when there is a risk of confusion.

What a console, a script and a runbook do not do

You can create an S3 bucket in three ways without Terraform: by clicking, by running a script, or by following a written procedure. Each has its place. None does the architect's job.

Terraform does what these three methods do not, and does it in this order: it reads the existing, it compares to the code, it announces what will change, it applies only what is missing, it notes what it did in the state, and it knows how to clean everything up with terraform destroy. Each project in the course ends with this destruction: nothing stays active, nothing stays billed.

The problem before Terraform

Imagine a company must launch a web application. It might need to create:

• a private network;
• subnets and firewall rules;
• servers or a Kubernetes cluster;
• a database;
• a load balancer;
• a domain name and certificates;
• technical accounts and permissions;
• storage, backups and monitoring.

You can create it all by hand in an AWS, Azure or Google Cloud console. That works for a first try. It becomes fragile as soon as the environment grows.

The six difficulties of the manual method

1. Actions are hard to repeat. Two people follow the same instructions and get different environments.
2. The real configuration is badly documented. A screenshot or a written procedure does not prove the infrastructure still matches the description.
3. Human errors multiply. A wrong port, wrong region or too-wide permission creates an outage or a security hole.
4. Environments diverge. Development works, but production has a different network rule or version.
5. Changes are hard to review. In a graphic interface, there is not always a clear history of who changed what, and why.
6. Rebuilding takes time. After a major outage, the team must remember hundreds of manual steps.

Reread the table of real examples: Decathlon describes the cost of the manual method (over a week, multiple teams and a CMDB to fill for a single server), GitHub addresses difficulty 1 (hosts built "the same way" everywhere), Slack addresses difficulty 5 (the estimate reviewed in the pull request before any merge).

Infrastructure as Code

Infrastructure as Code, abbreviated IaC, consists of describing infrastructure in files treated as code. HashiCorp defines Terraform as an IaC tool that lets you define cloud and on-premise resources in readable configuration files, which you can version, reuse and share. Official reference — Introduction to Terraform

Instead of writing a long procedure like "click here, choose this region, then create this network", you describe the desired state:

resource "aws_s3_bucket" "documents" {
  bucket = "company-documents-example"
}

This block does not describe each API call. It says: "this bucket must exist with this configuration". That is the architect's blueprint. Terraform then figures out what work is needed.

What Terraform brings

1. Repeatability

The same code creates a development, test or production environment. Values that change are placed in variables rather than copied by hand.

2. Visibility before change

terraform plan shows the creations, modifications and deletions to come: that is the work estimate. The team reviews the intent before Terraform touches the infrastructure. Symbols are fixed by official documentation. Official reference — terraform plan

+   create
~   modify in place
-/+ replace (destroy, then recreate)
-   destroy

Caution: a plan reduces risk, it does not guarantee no impact. A network, database or identity change stays dangerous and must be reviewed line by line.

3. A history in Git

.tf files live in Git. Each change is tied to a branch, a merge request, a review and an author. That is what Slack does: the estimate is posted in the pull request, and nobody merges without reading it.

4. Standardization

An organization wraps its rules in reusable modules: mandatory encryption, cost tags, logs enabled, approved network and controlled versions. Modules let you reuse configurable collections of resources. Official reference — Terraform Modules

5. Lifecycle automation

Terraform is not just for creating. It compares the configuration, the state and the real infrastructure to figure out what to add, modify or remove. That is the architect's gesture: reread the blueprint, open the record, go see the building.

Why a company pays to automate

Terraform requires an upfront investment: learn HCL, write modules, secure the state and build an approval chain. That investment pays for itself as soon as the team must repeat, audit or evolve the infrastructure.

Example: a company owns 30 applications and four environments per application. By hand, that is 120 environments to maintain. Common modules let you describe the pattern once and provide values specific to each application.

Terraform does not replace human judgment

Terraform automates an intent. If the code asks for bad architecture, Terraform reproduces that bad architecture very efficiently, and everywhere. You must always:

• understand the plan;
• limit permissions;
• protect secrets and state;
• test changes;
• plan for rollback and recovery;
• watch costs and availability.

The architect does not build what he wants. He builds what is drawn. If the drawing is bad, the building will be too.

The cycle in one picture: blueprint, record, building

Read the diagram from left to right. The blueprint and the record go to the architect. He goes to see the building. He produces an estimate. You sign it. The trades execute, and the architect updates his record. Next time, if nothing moved, the estimate is empty: No changes.

The essentials

1. Terraform is the architect who compares the blueprint (your code), the record (the state) and the building (the cloud), then only has the missing work done.
2. The code is declarative: you describe the result, not the steps; rerun without change, Terraform touches nothing, that is idempotence.
3. The state is Terraform's memory: without it, it does not recognize what it built; it is sensitive and must be protected.
4. The console explores, the script creates, the runbook tells; only Terraform reads the existing, detects drift, announces the change before making it and knows how to clean everything up.
5. Terraform automates an intent, it does not judge it: a plan is read line by line, even when the code change looks small.

Questions for understanding

1. Why is a procedure with screenshots not a sufficient source of truth?
2. What is the difference between describing a result and writing all the steps to get it?
3. Why is terraform plan useful before production?
4. In what case would the upfront investment of IaC be not very profitable?
5. In the architect picture, what do the blueprint, the record and the building represent? And the estimate?
6. Someone adds a firewall rule in the console, without going through the code. What is this gap called, and when does Terraform notice it?