The temptation to copy and paste
The development environment already works. Acceptance is needed: you copy the folder, change a few names and you are done. Then production, another copy. Within a year there are six copies that started identical and no longer are. Somebody fixes a security flaw in one and forgets the other five.
It is the same problem an application's code has when it is duplicated, and the solution is the same: a single definition that gets reused.
What a module is
A module is a block of infrastructure with a clear purpose and a few parameters. For example, 'a web service with its load balancer, its database and its network rules', where the parameters are the size, the number of instances and the environment name.
Each environment uses the module with its own values; it does not copy it. If the module is fixed, the fix reaches every environment that uses it.
How to design a good module
| Good | Bad |
|---|---|
| A purpose you can explain in one sentence | 'Everything for application X' |
| Few parameters, with safe defaults | Dozens of parameters to cover every case |
| Secure by default: encryption on, nothing exposed | Insecure unless configured |
| Versioned: each environment pins which version it uses | Always the latest, for everyone at once |
| Documented with a usage example | You have to read the code to use it |
Versioning to change calmly
Every environment using the same definition does not mean they all change at once. Each environment declares which version of the module it uses. An improvement is tested first in development, then in acceptance and finally in production, like any other change.
Reusing well reduces errors. But every change still carries risk, and before applying it you need to see exactly what it is going to do. That is what the plan is for.
How we apply it: Automation and IaC.