📋 Infrastructure as Code

The Blueprint Analogy

Building a house:

Infrastructure as Code (IaC) treats server and cloud setup like blueprints - define everything in code, rebuild identically every time.

Why Infrastructure as Code?

The Manual Nightmare

Old way to set up a server:

1. Click "Create Instance" in AWS console
2. Click "Configure networking..."
3. Click "Add security rules..."
4. SSH in, run various commands...

The IaC Solution

Define in code, run command, infrastructure created.

Core Principles

1. Declarative vs Imperative

Most IaC tools are declarative - you describe the end state, the tool figures out how to get there.

2. Idempotency

Running the same code multiple times produces the same result:

Typically fine to run repeatedly.

3. Version Control

infra/
├── main.tf           ← Infrastructure definition
├── variables.tf      ← Configurable values
└── README.md

Git history:
  "Added Redis cache cluster"
  "Increased web servers to 5"
  "Rolled back database change"

Full history of every infrastructure change!

How IaC Works

The Workflow

1. WRITE     → Define desired infrastructure in code
      ↓
2. PLAN      → "What changes will this make?"
      ↓
3. REVIEW    → Team reviews the plan
      ↓
4. APPLY     → Tool makes reality match code
      ↓
5. STATE     → Tool tracks what exists

State Management

State is the source of truth for what infrastructure actually exists.

Popular IaC Tools

Terraform Example

resource "aws_instance" "web" {
  ami           = "ami-12345"
  instance_type = "t3.micro"
}

Declare what you want → Terraform creates it.

IaC vs Configuration Management

Often used together: Terraform creates servers, Ansible configures them.

Benefits of IaC

Reproducibility

Same code, same environment, anywhere.

Disaster Recovery

Data center burns down?

All you need is the code (in version control).

Documentation

The code IS the documentation.

Review Process

1. Open pull request with infra changes
2. terraform plan shows exactly what will change
3. Team reviews before applying
4. Merge and apply

No more: "Someone changed production, what happened?"

Common Patterns

Modules: Reusable Components

Define complex infrastructure once, reuse everywhere:

module "web_app" {
  source = "./modules/web-app"
  name   = "my-app"
  size   = "large"
}

"Large web app with load balancer, autoscaling, and database" in one line.

Environments

environments/
├── dev/       ← Smaller instances, lower cost
├── staging/   ← Production-like for testing
└── prod/      ← Full production scale

Same modules, different configurations per environment.

Common Mistakes

1. Manual Changes After IaC

2. Not Reviewing Plans

Typically review terraform plan before applying:

Read the plan each time you apply changes.

3. Storing State Locally

4. Hardcoding Secrets

Avoid committing passwords or API keys in IaC code. Use:

• Secret managers (AWS Secrets Manager, Vault)
• Environment variables
• Encrypted data sources

FAQ

Q: IaC for small projects?

Yes! Even simple setups benefit from reproducibility and documentation.

Q: Terraform vs CloudFormation?

CloudFormation: AWS-focused, included with AWS (you pay for the resources), deep AWS integration Terraform: Multi-cloud, larger community, more flexibility

Q: What about existing infrastructure?

Most tools can import existing resources. Then manage them as code going forward.

Q: How do I start?

Terraform + AWS/GCP free tier. Deploy a simple web server. Iterate from there.

Summary

Infrastructure as Code manages cloud and server resources through version-controlled, repeatable code files.

Key Takeaways:

• Define infrastructure in code, not clicks
• Declarative: describe end state, tool handles the rest
• Idempotent: designed to converge when applied repeatedly
• Version controlled: full history, code review
• Reproducible: same code = same infrastructure
• Popular tools: Terraform, CloudFormation, Pulumi
• Try to avoid manual changes after applying!

IaC brings software engineering discipline to infrastructure!