Dos formas de pedir lo mismo
Supón que necesitas tres servidores detrás de un balanceador. Hay dos maneras de escribirlo.
Ordenando (un script): crea un servidor, crea otro, crea un tercero, crea el balanceador, conecta los tres. Funciona la primera vez. ¿Y la segunda? Crea tres servidores más. ¿Y si ya había dos? Crea tres, y quedan cinco. ¿Y si falla en el paso cuatro? Queda a medias, y hay que adivinar qué se hizo.
Declarando (infraestructura como código): "deben existir tres servidores de este tamaño detrás de un balanceador". Una herramienta compara lo declarado con lo que existe y hace solo lo que falta.
Por qué declarar es más seguro
- Se puede repetir sin miedo. Ejecutar dos veces lo mismo deja el mismo resultado. Si ya está como debe, no se toca nada.
- Lo existente se respeta. Si dos de los tres servidores ya existen, solo se crea el tercero.
- Los fallos se recuperan. Si algo falla a mitad, se vuelve a ejecutar y la herramienta continúa desde donde quedó.
- El código se lee como una descripción. Quien lo abre ve qué hay, no una receta que tiene que ejecutar en la cabeza para entenderla.
Cuándo se sigue necesitando ordenar
Algunas tareas son pasos por naturaleza: migrar datos, rotar una clave, reiniciar servicios en un orden concreto. Para esas, los scripts siguen siendo la herramienta adecuada, con dos condiciones: que comprueben antes de actuar (no crear lo que ya existe) y que se puedan repetir sin romper nada.
Declarar lo que debe existir tiene una consecuencia práctica: la herramienta necesita recordar qué creó y cómo lo relaciona con el código. Esa memoria es el estado.
Cómo lo aplicamos: Automatización e IaC.