What is Infrastructure as Code, and what problems does Terraform solve compared to manual provisioning?
Quick Answer
Infrastructure as Code (IaC) means defining infrastructure (networks, servers, databases, IAM) in versioned, machine-readable configuration files instead of clicking through a console. Terraform is a declarative, provider-agnostic IaC tool: you describe the *desired end state*, and it computes and executes the plan to get there. This gives you reviewable diffs (`terraform plan`), reproducibility across environments, a single workflow across many clouds, and an auditable history — eliminating configuration drift and "nobody remembers how this was set up" tribal knowledge.
Detailed Answer
Before Infrastructure as Code, provisioning meant clicking through a cloud console (or running one-off scripts) to create a VPC, a few servers, a load balancer, and some IAM roles. That approach — often called ClickOps — has several structural problems that show up as soon as more than one person or environment is involved:
- No source of truth. The only record of "how staging is configured" is whatever's currently live in the console. If someone changes a setting by hand, there's no diff, no history, and often no idea who changed it or why.
- Non-reproducible environments. Standing up a second identical environment (a new region, a disaster-recovery copy, a fresh dev sandbox) means manually repeating dozens of clicks and hoping nothing was missed. In practice, environments drift apart over time ("works in staging, breaks in prod").
- No review process. A risky change to production infrastructure — deleting a security group rule, resizing a database — happens directly, with no equivalent of a pull request or code review before it takes effect.
- Tribal knowledge. Institutional knowledge about why something is configured a certain way lives in people's heads or old Slack threads, not in a durable, searchable artifact.
Terraform addresses this by making infrastructure declarative and versioned:
resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.micro"
tags = {
Name = "web-server"
}
}
- You describe the desired end state in HCL files that live in git, alongside application code.
terraform plancomputes exactly what would change before anything happens — the equivalent of a diff/code review for infrastructure.terraform applyexecutes that plan and records the result in a state file, so Terraform always knows what it manages and can detect drift later.- The same configuration can be reused across environments (dev/staging/prod) with different variable values, guaranteeing structural consistency.
- Because it's just text, it goes through the same PR review, CI checks, and audit trail as application code.
The net effect: infrastructure changes become reviewable, repeatable, and auditable — the same guarantees you already expect from application code, applied to the servers, networks, and services that code runs on.