LibraryFirst Way: FlowTools & TechniquesInfrastructure as Code

FT-10TOOLFirst Way: Flow

Infrastructure as Code

Servers defined in files, not manual clicks. How to version-control your infrastructure, eliminate snowflake servers, and apply the same quality practices to infrastructure that you apply to application code.

Sources:DevOps HandbookInfrastructure as Code — MorrisTerraform docs

Video Lesson

A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.

01

What is IaC?

Infrastructure as Code is the practice of managing infrastructure — servers, networks, databases, load balancers — through machine-readable configuration files rather than manual processes or interactive configuration tools. The files are version-controlled, reviewed, and applied through automated pipelines.

The problem IaC solves is the snowflake server: a server that has been manually configured and patched over time until it is unique and irreplaceable. Nobody knows exactly what is on it. It cannot be reproduced. When it fails, recovery is unpredictable.

Snowflake server

Manually configured over months/years

Undocumented dependencies and tweaks

Cannot be reproduced from scratch

Recovery from failure is unpredictable

"It works, don't touch it"

IaC-managed server

Defined in version-controlled config files

Every change is reviewed and audited

Can be reproduced identically in minutes

Recovery: destroy and recreate from code

"Delete it and rebuild" is routine

IaC is not just about efficiency. It is about confidence. When infrastructure is defined in code, you know exactly what you have, you can reproduce it, and you can change it safely — with the same practices (review, test, staged rollout) as application code.

02

Declarative vs imperative

IaC tools fall into two categories based on how you express the desired infrastructure state:

Declarative — Terraform

# Describe what you want

resource "aws_instance" "web" {

ami = "ami-0c55b159cbfafe1f0"

instance_type = "t3.micro"

}

Terraform figures out how to achieve the desired state. You describe the end result. The tool handles the steps.

Imperative — Ansible

# Describe how to get there

- name: Install nginx

apt:

name: nginx

state: present

Ansible executes instructions in order. You describe the procedure. Useful for configuration management on existing servers.

Terraform

Declarative

Cloud infrastructure — VMs, networks, databases, DNS

HCL

Pulumi

Declarative

Cloud infrastructure using real programming languages

TypeScript / Python

Ansible

Imperative

Server configuration management, app deployment

YAML

Docker Compose

Declarative

Local development and single-host container orchestration

YAML

Kubernetes

Declarative

Container orchestration at scale

YAML / Helm

03

Immutable infrastructure

Immutable infrastructure takes IaC to its logical conclusion: instead of patching or updating running servers, you replace them entirely. When a change is needed, build a new image with the change baked in, provision new infrastructure from it, and decommission the old.

Docker containers are the canonical expression of immutable infrastructure. A container image is built once, promoted unchanged through environments, and never modified in place. If you need a different configuration, build a new image.

Mutable servers

SSH in. Run apt upgrade. Edit config files. The server accumulates changes over time. State diverges from the original spec.

IaC-managed servers

Changes are made in config files and reapplied. Better — but the server can still drift between applies, and partial failures leave unknown state.

Immutable servers

Never modify a running server. Build a new image. Deploy new servers. Destroy old ones. Every server is known, reproducible, drift-free.

04

IaC in the pipeline

Infrastructure code goes through the same pipeline as application code: lint, validate, plan, and apply. The critical step is plan before apply — Terraform's plan command shows exactly what will change before any resource is created or destroyed. Treat the plan output as a required review artifact.

Lint

tflint / checkov

Style, syntax, and basic security checks. Fast. Runs on every commit.

Validate

terraform validate

Checks configuration is syntactically valid and internally consistent.

Plan

terraform plan

Shows exactly what will change. Required review before apply. No resources created.

Apply

terraform apply

Creates, updates, or destroys resources. Automated in CI for staging. Manual approval for prod.

Never run terraform apply manually in production

All applies are triggered by the pipeline after a successful plan review. Manual applies bypass review and break audit trails.

Store state remotely

Terraform state must be stored in a remote backend (S3, Terraform Cloud) — not locally. Local state cannot be shared or locked.

Lock state during applies

Prevent concurrent applies that would corrupt state. Remote backends provide locking automatically.

05

IaC at Nexus Corp

In Mission 02, Nexus Corp's infrastructure was defined in a docker-compose.yml — a declarative, version-controlled specification of the application stack. This is the foundation of IaC thinking applied to local development. The progression to full IaC looks like:

M-02 (done)

Docker Compose

Local + CI environment definition

✓ In place

Next step

Dockerfile

Immutable production container image

Builds from M-02 base

Intermediate

Render config

PaaS deployment spec (render.yaml)

Declarative deploy config

Full IaC

Terraform

Cloud resources: DB, CDN, DNS, networking

When self-hosting

06

Further reading

Infrastructure as Code — Kief Morris

The comprehensive guide to IaC principles and patterns. Tool-agnostic. Covers immutability, testing infrastructure code, and pipeline design.

DevOps Handbook — Chapter 14

Enable and Practice Infrastructure-as-Code. Environment provisioning, configuration management, and the path from snowflake to code-defined infrastructure.

Terraform: Up and Running — Brikman

The practical Terraform book. Module design, state management, testing, and multi-environment workflows. Updated for Terraform 1.x.

The Phoenix Project — Part II

Brent and the snowflake servers. The narrative that made infrastructure debt legible. Chapter 14–18: the cost of undocumented, irreproducible infrastructure.