infra-as-code

Infrastructure as code

Infra changes through code review and version control, not through clicking in the cloud console. Anything else drifts into "only Alice knows how this cluster was set up."

Principles

• Everything in version control. Every resource that exists in prod should exist in code. If it's manual, fix it.
• Declarative over imperative. Describe the desired state; let the tool figure out the diff. (Terraform, Pulumi with state, CloudFormation, Kubernetes manifests.)
• Reviewable. Every change goes through a PR. Plan output is visible to reviewers.
• Reproducible. From an empty account, the code should reconstruct the infrastructure.
• Rollback-able. Revert a commit, reapply, get the old state back.

Tool choice

• Terraform / OpenTofu — dominant, cloud-agnostic, mature, HCL syntax. State file is load-bearing.
• Pulumi — real programming languages, good for teams that hate HCL. State model similar to Terraform.
• CloudFormation / CDK — AWS-native, tight integration, less cloud-agnostic.
• Kubernetes manifests / Helm / Kustomize — for k8s-specific resources.

Pick one primary, be consistent. Mixing creates drift.

Structure

Modules

Extract repeatable patterns into modules: "a web service," "a VPC with public/private subnets," "a Postgres instance with backups."

• Inputs are small, named, typed.
• Outputs are what callers need to wire into other modules.
• Modules should be stable. Breaking changes = new version.

Environments

• Separate state per environment. Don't share state between dev and prod.
• Same code, different inputs. The same module used for dev and prod with different parameters (size, region, replicas).
• Dev is not a stripped-down prod. It should exercise the same code path.

Directory layout (typical)

infra/
├── modules/
│   ├── web-service/
│   ├── database/
│   └── vpc/
├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/
└── README.md