Los entornos de TI han crecido en escala y complejidad en los últimos años, y el aprovisionamiento manual de servidores, redes y bases de datos ya no sigue el ritmo exigido por los negocios. Configurar un entorno manualmente, elemento por elemento, puede llevar semanas y deja margen para fallos que solo aparecen más adelante, cuando el sistema ya está en producción.
La infraestructura como código responde a este cuello de botella tratando los servidores y las redes como cualquier otra parte del software: descritos en archivos, versionados y probados antes de entrar en funcionamiento. Jean Pierre Lessa e Santos Ferreira, director de tecnología, señala que este cambio modifica menos la tecnología disponible que la forma en que los equipos se organizan en torno a ella.
¿Qué cambia cuando la infraestructura se convierte en código?
En la práctica, la infraestructura deja de ser un conjunto de ajustes realizados manualmente en cada servidor y pasa a ser un archivo de configuración que describe el estado deseado del entorno. Una herramienta interpreta este archivo y crea, ajusta o elimina recursos automáticamente, sin que alguien tenga que repetir el mismo procedimiento en cada máquina. El archivo entra en el mismo flujo de trabajo utilizado para el código de la aplicación: se almacena en un repositorio, pasa por una revisión antes de ser aprobado y mantiene un historial de cambios.
Si es necesario recrear un servidor desde cero después de un fallo, el mismo registro garantiza que el nuevo entorno sea idéntico al anterior, sin depender de la memoria de quien realizó la configuración original. Los picos previsibles de demanda también resultan más sencillos de gestionar: en lugar de mantener capacidad adicional inactiva durante todo el año, el equipo define la regla de expansión una sola vez y permite que se aplique automáticamente cada vez que el volumen de accesos lo requiera.
¿Cómo incorporan los equipos este modelo en su día a día?
Para Jean Pierre Lessa e Santos Ferreira, este cambio de ritmo afecta directamente al calendario de los proyectos, ya que los entornos de prueba pueden crearse bajo demanda y eliminarse después de su uso. La rutina de quienes se encargan de la infraestructura cambia de enfoque: en lugar de ejecutar comandos aislados ante cada solicitud, el equipo pasa a escribir y mantener módulos reutilizables, probados como cualquier otra parte del sistema.
Aprovisionar un nuevo entorno deja de ser una tarea de varios días y se convierte en una cuestión de minutos, lo que reduce las esperas entre equipos que antes dependían unos de otros para disponer de un nuevo entorno. La práctica de mantener servidores inactivos simplemente porque recrearlo todo desde cero resultaba demasiado laborioso pierde sentido con este modelo, ya que cualquier entorno puede reconstruirse bajo demanda.
Los efectos en la colaboración entre desarrollo y operaciones
Cuando la infraestructura es código, puede ser revisada, probada y aprobada por las mismas personas que se encargan de la aplicación, y no únicamente por quienes administran los servidores. Esta aproximación reduce la distancia entre los equipos de desarrollo y operaciones, históricamente separados por procesos y lenguajes de trabajo diferentes a lo largo de décadas de organización de las áreas tecnológicas.
Según el análisis de Jean Pierre Lessa e Santos Ferreira, esta convergencia tiende a distribuir la responsabilidad por la estabilidad del entorno entre más personas, en lugar de concentrarla en un pequeño grupo al que solo se recurre cuando algo falla. Como efecto adicional, el equipo de operaciones suele estar menos sobrecargado por solicitudes repetitivas, ya que buena parte de los ajustes rutinarios pasa a resolverse en el propio código antes de llegar a producción.
Los cuidados que exige la adopción
Tratar la infraestructura como código no elimina los riesgos, sino que los desplaza. Un archivo de configuración mal escrito puede replicarse con la misma rapidez con la que se corrige un problema, y un pequeño fallo puede propagarse por todos los entornos al mismo tiempo, en lugar de quedar restringido a una única máquina, como ocurría con el modelo manual.
Por este motivo, las pruebas automatizadas y la revisión rigurosa de los archivos de configuración dejan de ser etapas opcionales. Jean Pierre Lessa e Santos Ferreira considera que el aumento de velocidad solo se mantiene cuando va acompañado de una disciplina equivalente en la validación, lo que convierte la adopción de este modelo menos en una elección de herramientas y más en un cambio cultural dentro del equipo de tecnología.
