Una pregunta incómoda
Imagina que mañana alguien borra por error todo un entorno: redes, servidores, bases de datos, reglas de acceso. Los datos están a salvo en sus copias, pero la infraestructura que los rodea ya no existe. ¿Cuánto se tarda en volver a tenerla exactamente como estaba?
En muchas organizaciones la respuesta honesta es "no lo sabemos", seguida de "días, y no quedaría igual". Nadie recuerda todas las reglas de red, los tamaños elegidos, los ajustes hechos a mano a lo largo de los años.
La infraestructura como código
La alternativa es describir toda la infraestructura en ficheros de texto: qué redes existen, qué servidores, con qué tamaño, qué reglas los protegen. Esos ficheros se guardan en un repositorio, se revisan como el código de una aplicación y una herramienta se encarga de que la realidad coincida con lo descrito.
Con eso, reconstruir deja de ser una hazaña y pasa a ser un comando. Y, de paso, se gana todo lo demás:
- Historial: cada cambio tiene autor, fecha y motivo.
- Revisión: un cambio en la red se revisa antes de aplicarse, igual que un cambio en el código.
- Repetición: desarrollo, aceptación y producción salen del mismo código, con distintos parámetros.
- Documentación que no miente: el código es la descripción de lo que existe.
Lo que recorre esta serie
Del problema de los clics a declarar el estado deseado; del código de la infraestructura (su estado, sus módulos, el plan antes de aplicar y su costo) a mantener cada servidor como debe ser y detectar cuándo se desvía; de cómo cambiar sin miedo (volver atrás, reglas como código, incorporar lo heredado) a automatizar la operación diaria. Y, al final, lo que conviene no automatizar.
Empecemos por el origen del problema: los clics.
Cómo lo aplicamos: Automatización e IaC.