El elefante en la consola
Leer sobre infraestructura como código desde cero es fácil. La realidad es otra: un entorno con cientos de recursos creados durante años, a mano, por personas que ya no están. Reescribirlo todo de golpe es inviable; dejarlo fuera significa que la parte más crítica nunca tendrá los beneficios del código.
Incorporar, no reconstruir
La mayoría de las herramientas permiten importar recursos existentes: se escribe el código que describe un recurso que ya existe y se le dice a la herramienta "este de aquí es ese de allí". Sin destruir ni recrear nada.
El trabajo se organiza por oleadas:
- Inventario primero. Saber qué existe de verdad, como en antes de arreglar, saber qué hay.
- Empezar por lo de más riesgo y menos cambio: red, identidades y accesos. Errores ahí son graves y estos recursos cambian poco, así que el código se mantiene estable.
- Seguir por los datos: bases de datos y almacenamiento, con mucho cuidado de no provocar recreaciones.
- Terminar por el cómputo, que es lo que más cambia y lo más fácil de reemplazar por versiones nuevas creadas ya desde código.
La regla de oro de la importación
Después de importar un recurso, el plan tiene que salir vacío. Si el plan propone cambios, el código no describe fielmente lo que existe y aplicarlo modificaría algo que funciona. Se ajusta el código hasta que el plan no tenga nada que hacer, y solo entonces se da por incorporado.
Lo que se queda fuera
No todo merece entrar. Recursos que se van a retirar pronto o experimentos sin uso se documentan como excepciones y se eliminan en lugar de importarse. El objetivo no es el 100 %, sino que lo importante esté en código y lo demás esté identificado.
Con la infraestructura en código, el siguiente paso natural es que también la operación diaria deje de depender de que alguien recuerde los pasos.
Cómo lo aplicamos: Automatización e IaC.