En este artículo se explicará una base fundacional sobre el concepto detrás de la Infraestructura como Código, sus ventajas, y en linea con lo anterior se justificará la razón del por qué las organizaciones están solicitando cada vez más profesionales que dominen las tecnologías y/o herramientas que permiten llevar esto adelante.
Es importante entender que hay distintos enfoques sobre la Infraestructura como Código (IaC por sus siglas en inglés), dependiendo del tipo de infraestructura que se esté administrando:
- Por un lado, para la infraestructura virtualizada/Cloud: Considerando que en este modelo es posible crear o destruir recursos (por ejemplo, máquinas virtuales) en la medida que ellos sean necesarios o no, existen herramientas que se especializan en automatizar esta tarea (más adelante explicaremos la necesidad y el por qué detrás de realizar esto). Algunas de ellas que ganaron bastante terreno durante los últimos años para este tipo de infraestructura (también llamada del tipo inmutable) son Terraform (Hashicorp, vendor-agnóstico) y CloudFormation (AWS).
- Por el otro lado, para la infraestructura física (llámese servidores, dispositivos de red, entre otros… también denominada con el término de mutable): dado que este caso no es posible crear o destruir recursos (bueno, destruir sería posible pero implicaría lanzar un Router desde un noveno piso 😜), las herramientas se especializan en mayor medida en la aplicación de cambios de configuración sobre los dispositivos. Algunas de ellas que ganaron su merecido lugar en este campo son Ansible y Puppet.
Un famoso cuestionamiento que suele presentarse es si Ansible es mejor que Terraform, o viceversa. Entendiendo los puntos anteriores, es posible responder que cada herramienta es muy buena en su campo específico de acción: por un lado, Ansible como herramienta de Config-Management, mientras que Terraform para la creación/destrucción de recursos virtualizados. Teniendo en cuenta lo anterior, es fácil ver que ambas se complementan muy bien: comenzando Terraform con el despliegue de los recursos, y continuando con Ansible en una segunda etapa para la configuración de los mismos (como uno de los tantos escenarios posibles, pudiendo incluir variaciones con otras tecnologías también).
🎥 Los invito a ver el siguiente video, en donde brindo un poco más de contexto sobre lo mencionado anteriormente y realizo una breve introducción sobre los beneficios que se detallarán a continuación:
Teniendo en cuenta lo anterior, por qué las empresas están adoptando cada vez más la IaC? Por qué se vuelve cada vez más relevante para los profesionales dominar estas herramientas?
Se intentará responder las preguntas anteriores con las siguientes razones:
Automatizacion y ahorro de tiempo
Si bien en un entorno Cloud el contar con recursos de manera casi inmediata a través de un modelo de servicios aumenta la velocidad de despliegue de infraestructura de forma considerable (en relación a comenzar de cero con infraestructura física propia), este esquema presenta también una serie de tareas repetitivas. Dichas tareas, convencionalmente deberían realizarse a través del dashboard para poder encender/apagar instancias, conectar servicios entre sí, habilitar conectividad entre ellos, entre otras cosas. Dado que los proveedores de Cloud facturan por uso del servicio, imagina tener que realizar estas tareas de manera periódica para optimizar el costo y evitar ser cobrado en horarios donde cierto servicio no se utiliza. La IaC optimiza significativamente el “ClickOps“ , o dicho de otra manera, tener que hacer infinidad de clicks en el dashboard para gestionar estos recursos diariamente.
Repetibilidad
A medida que el tamaño de la infraestructura escala, generalmente se desea mantener cierta consistencia en la configuración de la misma, por diferentes motivos: razones de compliance internos de cada empresa, seguridad, mejores prácticas, garantizar presencia de configuraciones ya probadas anteriormente, etc.
El hecho de definir la infraestructura como código, permite al reutilizar módulos de configuración que todos los recursos del mismo tipo sean configurados de la misma manera!
Configuración imperativa vs. declarativa
Herramientas como Terraform plantean un cambio en el paradigma de configurar equipos teniendo que conocer antemano los 146 comandos CLI, y en su orden específico, para llegar del punto A al punto B (lo que se conoce tradicionalmente como configuración de manera imperativa). Por el contrario, lo que Terraform (entre otras herramientas) permite hacer es definir la configuración de recursos de manera declarativa. Qué quiere decir esto?
Como vemos en la imagen anterior, si imaginamos que nuestro amigo al cual se le enciende la lamparita es Terraform, se observa que al comparar el estado actual de la infraestructura con el estado futuro deseado (descripto en manera de codigo en un archivo de configuración/deploy), él cuenta con la inteligencia suficiente para detectar cuál es el cambio a realizar para llegar del punto A al punto B y el orden necesario de los pasos.
Control de versiones
Imagina el siguiente escenario: Se hace deploy de un archivo de configuración, y un parámetro errado en un lugar recóndito del código hace que se indisponibilice un servicio crítico para la empresa. Cuál fue la causa? Cómo se soluciona lo antes posible?
Por suerte para nosotros, como estamos hablando de código, indudablemente está involucrada una herramienta de control de versiones como Git. Para poder identificar el cambio que impactó el servicio, bastaría con revisar commits anteriores, y eventualmente realizar rollback del último cambio volviendo al commit respectivo, y realizando deploy nuevamente. Sin necesidad de tener que identificar una linea de comando en especifico! 😁
Control de cambios y colaboración
e refiere a mantener un registro organizado y sistemático de todas las modificaciones que se realizan en el código que describe la configuración de la infraestructura.
Al mismo tiempo, existen diferentes mecanismos que permiten combinar los cambios realizados por diferentes personas en el mismo código. Cuando varias personas trabajan juntas en el mismo proyecto de infraestructura, es importante asegurarse de que sus cambios sean compatibles, y no solo eso, sino que a la hora de aplicar cambios no se pisen el uno al otro sobre el trabajo que se está realizando (esto podría llegar a implicar borrar un servidor por no contar con la versión actualizada del código que alguien está trabajando en paralelo 😱)
La ventaja de tener un sistema de control de cambios y aprobación de merges en IaC radica en la colaboración segura y ordenada. Permite que varias personas trabajen en el mismo proyecto sin sobrescribir accidentalmente el trabajo de los demás. Antes de que los cambios sean aplicados a la infraestructura real,¿ existe la posibilidad de someterlos a un proceso de revisión y prueba, lo que disminuye el riesgo de errores y despliegues accidentados.
Te pareció útil esta información? Conoces alguna otra ventaja que quisieras compartir? Lo leo en los comentarios 🤓👇🏻