¿Qué es la infraestructura como código? y ¿De dónde viene?
Para comprender qué es la infraestructura como código (IaC), primero debemos comprender de dónde proviene y por qué se creó.
Cómo eran las cosas antes.
Tradicionalmente, al administrar la infraestructura del servidor de aplicaciones, el primer paso es diseñar la arquitectura más adecuada para su aplicación, es decir, un servidor simple para alojar su aplicación y una base de datos para almacenar los datos.
Después de elegir un proveedor, todo debe crearse y configurarse manualmente sobre la marcha. Comprar los servidores, conectarse a ellos, instalar o actualizar las dependencias que faltan para ponerlo al día y listo para usar, cargar y configurar la aplicación, etc.
Idealmente, todo este proceso debería estar bien documentado de forma comprensible, por lo que cualquier ingeniero debería poder replicarlo en caso de necesidad. Pero, lamentablemente, no siempre es así.
Imagínese que después de unos meses tiene un par de cientos de usuarios usando su producto, y se asusta mucho al darse cuenta de nuevas funcionalidades en producción porque ¿adivinen qué? ¡A veces se rompe! Y el sistema está inactivo durante un par de horas.
La solución sería crear un nuevo entorno exactamente como el de producción pero sin acceso de usuarios, solo para que los desarrolladores prueben y depuren nuevas funciones. Pero esto significa obtener otro servidor, configurarlo manualmente, implementar la aplicación, etc. ¿Y adivinen qué? ¡Eso toma mucho tiempo!
O tal vez solo quiera:
- Actualizar las dependencias de su servidor para evitar problemas de seguridad
- Corregir un error
- Agregar una nueva librería / dependencia
Este proceso se convierte en una molestia porque no hay forma de que pueda cambiar su configuración fácilmente. Podría pensar, “bueno, hay un documento que explica cómo configurar un servidor para que no sea tan doloroso o requiera tanto tiempo como la primera vez”, en teoría, eso es correcto, pero …
Quizás la aplicación haya cambiado tanto después de esos meses que requiera diferentes dependencias o versiones que no están en la documentación, o esté escrita en un idioma específico que no es fácil de entender para otros miembros del equipo, o incluso puede que no exista ningún documento. ¡en absoluto!
Pero hay una luz al final del túnel…
La infraestructura como código viene como la solución a todos los casos mencionados anteriormente: la configuración de la arquitectura está escrita en código en archivos que se cargarán en un servicio de intérprete, que creará todos esos recursos mediante programación.
Entonces, en este caso, también comenzamos con el primer paso de pensar en el diseño de la arquitectura de su aplicación, pero el segundo paso es muy diferente.
Después de elegir un proveedor de nube, se crean algunos archivos de plantilla compatibles con el servicio de intérprete del proveedor. Una vez que se haya escrito la definición de su arquitectura, solo necesita cargarla en el servicio de intérprete, y él se encargará de implementar y configurar todos esos servicios por usted.
Una vez que todo esté configurado, puede cargar su código por separado, pero hay herramientas interesantes para implementar su código en el proceso, por lo que puede implementar todo a la vez.
Esto brinda la posibilidad de crear nuevos entornos fácilmente a partir del mismo código, que será idéntico al entorno de producción para poder depurar un error o probar nuevas funciones. Además, esos archivos generalmente se almacenan en un sistema de control de versiones, por lo que todo el equipo puede tener acceso y sincronizarse, y es muy fácil volver a una configuración anterior si desea deshacerse de un problema que no detectó antes. o simplemente deshacerse de un cambio.
Muchos proveedores de nube ofrecen esta opción para administrar sus servicios, es decir: AWS CloudFormation, Azure Resource Manager.
Esto ha abierto el mercado para herramientas “independientes del proveedor”, como Serverless Framework y Terraform, que le permiten escribir el código de su infraestructura una vez, ¡y se traducirá en cualquier proveedor en el que desee implementar!
Conclusión
Los equipos que adoptan IaC pueden construir, implementar y replicar entornos más rápidos y confiables donde las situaciones de “funciona en la etapa de pruebas pero falla en la producción” ya no están en la mesa.
Eso es lo que hacemos en The Agile Monkeys, siempre apostamos por las tecnologías más confiables y resistentes, para maximizar la calidad de todo lo que construimos.
Realmente lo alentamos a que ingrese al mundo de IaC si está interesado en DevOps, ¡realmente es un cambio de juego!
