Infrastructure as Code Concepts

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure through machine-readable configuration files instead of manual processes.

Why Infrastructure as Code?

Before IaC, teams provisioned servers by clicking through cloud consoles or running ad-hoc scripts. This led to:

• Configuration drift — servers diverge over time because changes aren't tracked
• Snowflake servers — each environment is slightly different, making bugs hard to reproduce
• No audit trail — nobody knows who changed what or when
• Slow recovery — rebuilding infrastructure after a failure takes hours or days

IaC solves all of these by treating infrastructure the same way you treat application code.

Key Benefits

Declarative vs Imperative

There are two approaches to IaC:

Declarative (What)

You describe the desired state and the tool figures out how to get there.

# Terraform (declarative)
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  tags = {
    Name = "web-server"
  }
}

You say "I want an EC2 instance with these properties." Terraform determines whether to create, update, or do nothing.

Imperative (How)

You write step-by-step instructions for what to do.

# Bash script (imperative)
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --instance-type t3.micro \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-server}]'

You say "Run this command to create an instance." If you run it again, you get a duplicate.

Which Is Better?

Declarative wins for infrastructure management because:

• It's idempotent — running it twice produces the same result
• It handles dependencies automatically
• It can detect drift and correct it
• It shows you a plan before making changes

The IaC Tool Landscape

Where Terraform Fits

Terraform is the most widely adopted IaC tool. It works with any cloud provider (AWS, Azure, GCP, DigitalOcean) through a plugin system called providers.

Your Code (HCL)
     │
     ▼
  Terraform CLI
     │
     ├──► AWS Provider ──► AWS API
     ├──► Azure Provider ──► Azure API
     └──► GCP Provider ──► GCP API

Key characteristics:

• Multi-cloud — one tool for all your providers
• State-based — tracks what exists so it knows what to change
• Plan before apply — shows you exactly what will happen
• Module system — reuse infrastructure patterns like code libraries
• Massive ecosystem — thousands of community modules on the Terraform Registry

IaC Workflow

The standard IaC workflow mirrors software development:

1. Write    ──► Define infrastructure in code
2. Review   ──► Open a PR, team reviews changes
3. Plan     ──► Preview what will be created/changed/destroyed
4. Apply    ──► Execute the changes
5. Verify   ──► Confirm infrastructure is healthy
6. Commit   ──► Merge to main branch

This brings all the benefits of software engineering — code review, CI/CD, testing, rollback — to infrastructure management.

When Not to Use IaC

IaC adds overhead. It might not be worth it for:

• One-off experiments — just use the console
• Tiny projects — a single static site on Vercel doesn't need Terraform
• Rapidly changing prototypes — IaC slows down exploration

But for anything going to production, anything with multiple environments, or anything a team manages together — IaC is essential.

Summary

• IaC manages infrastructure through code instead of manual processes
• Declarative tools like Terraform describe the desired state, not the steps
• Terraform is multi-cloud, state-based, and has the largest ecosystem
• The IaC workflow mirrors software development: write, review, plan, apply
• Use IaC for anything production-grade or team-managed