La tentación de copiar y pegar
Ya funciona el entorno de desarrollo. Hace falta aceptación: se copia la carpeta, se cambian unos nombres y listo. Luego producción, otra copia. Al año hay seis copias que empezaron iguales y ya no lo son. Alguien corrige un fallo de seguridad en una y olvida las otras cinco.
Es el mismo problema que tiene el código de una aplicación cuando se duplica, y la solución es la misma: una sola definición que se reutiliza.
Qué es un módulo
Un módulo es un bloque de infraestructura con un propósito claro y unos pocos parámetros. Por ejemplo, "un servicio web con su balanceador, su base de datos y sus reglas de red", donde los parámetros son el tamaño, el número de instancias y el nombre del entorno.
Cada entorno usa el módulo con sus valores; no lo copia. Si el módulo se corrige, la corrección llega a todos los entornos que lo usan.
Cómo se diseña un buen módulo
| Bien | Mal |
|---|---|
| Un propósito que se explica en una frase | "Todo lo de la aplicación X" |
| Pocos parámetros, con valores por defecto seguros | Decenas de parámetros para cubrir cada caso |
| Seguro por defecto: cifrado activado, nada expuesto | Inseguro salvo que se configure |
| Versionado: cada entorno fija qué versión usa | Siempre la última, para todos a la vez |
| Documentado con un ejemplo de uso | Hay que leer el código para usarlo |
Versionar para cambiar con calma
Que todos los entornos usen la misma definición no significa que cambien a la vez. Cada entorno declara qué versión del módulo usa. Una mejora se prueba primero en desarrollo, después en aceptación y al final en producción, como cualquier otro cambio.
Reutilizar bien reduce errores. Pero cada cambio sigue teniendo riesgo, y antes de aplicarlo hay que ver exactamente qué va a hacer. Para eso existe el plan.
Cómo lo aplicamos: Automatización e IaC.