La pieza invisible
Cuando una herramienta de infraestructura como código crea un servidor, apunta en algún sitio que "este servidor del código corresponde a este recurso real, con este identificador". Ese registro es el estado. Gracias a él, la siguiente vez sabe qué ya existe, qué cambió y qué tiene que crear o borrar.
Mientras todo funciona, nadie piensa en él. Cuando se pierde, se corrompe o dos personas lo modifican a la vez, la herramienta deja de saber qué es suyo, y las consecuencias van desde duplicados hasta borrados que nadie pidió.
Reglas para el estado
Nunca en un portátil. El estado vive en un almacenamiento compartido y remoto, no en la máquina de quien ejecutó el último cambio.
Con bloqueo. Mientras alguien aplica un cambio, nadie más puede hacerlo. Dos cambios simultáneos sobre el mismo estado son la receta clásica para corromperlo.
Con versiones. Cada cambio del estado guarda una copia de la versión anterior. Si algo sale mal, se puede volver.
Cifrado y con acceso restringido. El estado puede contener datos sensibles (direcciones, identificadores, a veces valores que el proveedor devuelve). Se trata como un secreto más.
Dividido por ámbito. Un estado gigante para toda la organización hace que cada cambio sea lento y arriesgado. Lo sano es separar por entorno y por área (red, datos, aplicaciones), de modo que un error en uno no alcance a los demás.
Nadie lo edita a mano
El estado se modifica solo a través de la herramienta. Editarlo a mano para "arreglar" algo es como cambiar el registro contable para que cuadre: el problema queda escondido, no resuelto. Si el estado y la realidad discrepan, se investiga por qué y se corrige con los comandos previstos para eso.
Con el estado bajo control, el siguiente problema es de escala: cómo describir veinte entornos sin copiar veinte veces el mismo código.
Cómo lo aplicamos: Automatización e IaC.