Making IaC boring
An IaC codebase takes shape before anyone names the architecture: the first migration, the account layout, the output path someone reaches for, the shared project that feels convenient. This series names those choices early enough for ownership, dependency direction, and tier membership to be reviewed before they become migration work.
- Start with the shape
By the time an IaC shape gets reviewed, the first migration, account layout, or whatever resource grew first has usually decided the boundary
- Resolve by contract
Resolve cross-tier dependencies by asking a producer for a typed capability in context instead of reaching into another stack's output path
- Define tier membership
Shared projects drift when service accounts, IAM bindings, and DNS records change with a workload but live in the environment tier
- Fail before apply
A contract only protects infrastructure when the release path resolves it, checks type and context, and refuses bad composition before provider calls run
- Re-cut the system
Repair starts by freezing the old boundary, publishing the new contract beside it, and deleting only after consumers have moved
- Appendix A: The shape, runnable
A placeholder companion repo makes the shape executable - four tiers, typed contracts, and resolver probes that refuse bad composition before any apply