Authoring Reusable Modules — Terraform & Infrastructure as Code

Every Terraform configuration is implicitly a module — the root module. But as infrastructure grows, repeating the same networking setup, EC2 autoscaling group pattern, or RDS cluster configuration across multiple deployments creates maintenance problems. A change to the RDS security configuration must be propagated to every place the RDS pattern is duplicated. Terraform modules solve this: a module is a reusable, self-contained infrastructure component with a defined interface (input variables) and outputs (output values). Calling a module passes values to its interface and receives outputs back. The module handles the implementation details. The consumer knows only the interface, not the internals. This encapsulation enables platform teams to build opinionated, organisation-approved infrastructure components that application teams consume without needing to understand the underlying resource configuration.

Analogy🏏Cricket

🏏 Think of it like cricket: Before standardised cricket rulebooks existed, every ground played by its own local customs — different LBW interpretations, different wide-ball rules, inconsistent DRS protocols. A touring team playing in a new city had to learn an entirely different set of rules. The standardised ICC rulebook is IaC: a version-controlled document that specifies exactly how cricket is played anywhere in the world. When any ground host asks 'how should this match be set up?', they apply the rulebook — not their memory, not local tradition, not a wiki page from 2019. Every ground becomes reproducible because they're all applying the same version-controlled specification. The insight is that codifying rules enables consistency at scale — you can run a thousand simultaneous cricket matches and every one follows the same rules because they all reference the same canonical document.