La era de la automatización IaC: la infraestructura como código.

Tras pasar años desde su adopción por startups y Big Tech, donde por antonomasia ocurre el I+D más destacado del sector, una nueva era de automatización IaC se extiende como la pólvora entre los equipos IT de organizaciones grandes, medianas y pequeñas de todo el mundo.

La automatización no es un concepto nuevo. Tradicionalmente, los equipos de infraestructura y aplicaciones TI han ido incorporando prácticas de automatización como los scripts o las plantillas, para evitar repetir las mismas operaciones manuales una y otra vez en tareas como clonar una máquina virtual o aplicar un cambio de software. Algunas de ellas ya han conseguido un estado de maduración muy sólido, como por ejemplo la realización de backups, que ya hace tiempo que se ejecutan diariamente de forma automática sin intervención técnica. Por tanto, la automatización ya está implantada en nuestros equipos IT.

Del mismo modo, en años venideros seguiremos automatizando nuestros procesos, explorando nuevas vías hacía la “Hiperautomatización” y la “aiops”. Cómo tecnólog@s buscaremos tecnologías que nos ayuden en esta labor, avanzando hacia un futuro donde lo que antes era innovación pasará a ser la actualidad del mercado e identificar los desafíos que debemos abordar será clave para tomar decisiones.

Veamos entonces algunos desafíos importantes que abordar:

• Aumento de sistemas y aplicaciones que gestionar.
• Mejorar la visibilidad, la documentación y la auditoría.
• Reducir los costes de infraestructura y gestión.
• Resolver problemas de escalabilidad de forma eficiente.
• Aumentar la agilidad y la velocidad con la que entregamos software.
• Eliminar las diferencias entre entornos.
• Reducir los tiempos de espera y los bloqueos entre equipos.
• Elevar a un primer plano la seguridad y la calidad del software e integrar procesos CI/CD.
• Vencer el miedo a confiar en un sistema automatizado, en el que los automatismos se ejecutan con una frecuencia alta.

Durante los últimos años hemos vivido cómo empresas de diferentes sectores, atraídas por la idea de llevar la automatización al siguiente nivel, llamaban a la puerta de la "Infraestructura como Código". Hemos cubierto todo el espectro: desde definir estrategias IaC para un sinfín de equipos responsables de redes, sistemas, almacenamiento, aplicaciones, bases de datos, desarrollo, seguridad y otras áreas, hasta implantarlas y crear las guidelines a seguir. También hemos formado a los equipos encargados de la transición, transformando juntos la operación de los sistemas. En este post quiero invitarte a repasar los pormenores de esta experiencia. ¿Preparad@s? ¡Vamos a ello!

Empecemos por el principio, ¿qué es IaC?

IaC son las siglas de infraestructura como código. Significa, en esencia, que escribiré la definición de los componentes de mis sistemas y sus configuraciones como código, en un "lenguaje de programación/configuración".

Esto posibilita dejar en segundo plano las interfaces gráficas para la operación y los cambios manuales unitarios, que sólo ponen palos en las ruedas de nuestra automatización al encontrarse fuera del “gitflow” en el que vamos a trabajar. Por tanto, IaC eleva a un primer plano el uso de un repositorio de código (git) como fuente de verdad. El uso de Git tiene un gran impacto a nivel global en el desarrollo de software, unas buenas prácticas que vamos a replicar en nuestros proyectos de infraestructura. Escribir todo como código implica adoptar nuevas metodologías, aprender a utilizar nuevas herramientas y, si bien existe una curva de aprendizaje, una vez superado el escalón inicial nunca más querrás mirar hacia otro lado.

Ejemplo escrito en HCL (Terraform):

resource "aws_instance" "host1" {
 ami           = "ami-0c55b159cbfafe1f0"
 instance_type = "t2.micro"
}

Bases para la construcción de estrategias IaC

Hemos visto unas pinceladas sobre las implicaciones de empezar con IaC. Hablemos más en profundidad de sus principios para enfocarnos después en el potencial de aplicar las estrategias en nuestros equipos de operaciones:

• Con IaC, los sistemas se pueden reconstruir de forma fiable fácilmente. Esto significa que eliminamos la necesidad de tomar decisiones importantes en el proceso de aprovisionamiento, como con qué nombre o qué versiones de software vamos a desplegar. Estas definiciones las realizamos en tiempo de diseño de la infra y podrán ser las mismas para todos los recursos en adelante hasta que decidamos unas nuevas, momento en el que podremos elegir si los cambios aplican a recursos que ya están creados. Ser capaces de aprovisionar entornos con poco esfuerzo elimina gran parte del riesgo y el miedo a realizar cambios.
• El código lo tenemos versionado en un repositorio. Permite beneficiarnos de las ventajas del ciclo de vida del software, aplicándolas en nuestro flujo de trabajo en infraestructura. Las Code reviews, issues y pull request nos ayudarán a mejorar la calidad de nuestro código y a distribuir mejor el conocimiento entre nuestros equipos. Tendremos mayor visibilidad y aumentará nuestra capacidad para revertir un cambio, pudiendo situar nuestros sistemas en un punto concreto del pasado para investigar problemas complejos. Más tarde nos permitirá establecer estrategias de integración y despliegue continuo.
• Los sistemas son consistentes. Dejar que las inconsistencias se cuelen en una infraestructura nos impide confiar en nuestra automatización ya que, al existir diferencias, una misma acción podrá potencialmente tener resultados diferentes. No tener automatizaciones degenera en sistemas inconsistentes. Debemos poder asegurar sin dudas que dos servidores que cumplan la misma función serán exactamente iguales y, para conseguirlo, emplearemos procesos automatizados para la provisión y los cambios que se realicen sobre ellos.
• Pequeños cambios en lugar de grandes cambios. Es más fácil y requiere menos trabajo probar un cambio pequeño y asegurarse de que sea sólido. También es más rápido avanzar o revertir un cambio pequeño que si aplico muchos cambios a la vez, momento en el que no sabré qué falla. Un problema pequeño con dependencias sobre un conjunto más grande retrasa el resto de cambios asociados que, aunque estén validados, deben esperar. Ver mejoras, aunque sean pequeñas, es motivador. Grandes cambios con tareas sin terminar que se acumulan pueden volverse obsoletos y es desmotivador.

• Los procesos son repetibles. Una vez automatizada una tarea, si necesitamos realizarla después, podremos repetirla de forma automática sin esfuerzo y mejorar/iterar la automatización en el caso de ser necesario. De esta forma siempre estamos construyendo valor encima de las bases sentadas ayer.
• El diseño siempre cambia. El mercado, nuestros clientes o los equipos de nuestras compañías son agentes que presionan a nuestros equipos de IT, lo que hace realmente complejo predecir qué definiciones de un sistema cambiarán con el tiempo. La medida más importante para garantizar que un sistema pueda cambiar de forma segura y rápida es realizar cambios con frecuencia, de forma que obliga a todas las partes implicadas a aprender buenas prácticas para gestionar los cambios, desarrollar procesos eficientes y optimizados e implementar herramientas que los respalden.
• Probar continuamente sistemas y procesos. En la mayoría de los casos, proteger un sistema minimizando el número de cambios realizados en él no lo hará más robusto. Pensemos en cómo hemos conseguido que realizar backups no forme parte de ningún hito vanguardista presente. Los equipos que ejecutan automatismos constantemente tienen sus procesos mucho más pulidos y están más preparados para manejar desastres e incidentes. La clave para una infraestructura antifrágil es asegurarse de que la respuesta predeterminada a los incidentes sea la mejora. De esta forma, la prioridad cuando algo sale mal no es simplemente solucionarlo, sino mejorar la capacidad del sistema para hacer frente a problemas futuros.
• Los sistemas son desechables. Que los sistemas se creen, se destruyan o se reemplacen fácilmente no es una desventaja, sino una característica que hace que sean más confiables y tolerantes a fallos. Piensa en este cambio de paradigma. Antaño teníamos un software poco confiable que dependía de un hardware muy confiable. Ahora no somos tan dependientes del hardware y tenemos un software que se ejecuta de manera muy confiable. Es tomar más control allí donde, por capacidad, podemos hacerlo. Con estas premisas podemos crear entornos efímeros que se apaguen si no se usan (por ejemplo, por la noche) y también sistemas más respetuosos con el medio ambiente.

Recapitulando, si tuviéramos que simplificarlo todo y resumirlo en tres pilares, serían estos:

• Definir todo como código.
• Probar y desplegar continuamente con mecanismos automatizados.
• Construir piezas pequeñas y simples que puedan cambiar de forma independiente.

Las herramientas de infraestructura como código, crean la oportunidad de trabajar realizando cambios con mayor frecuencia, rapidez y de manera más confiable, lo que mejora la calidad general de nuestros sistemas. Pero los beneficios no provienen de las herramientas, sino de cómo las usamos.

Que una funcionalidad nueva suba a producción más rápido significa responder de forma más ágil a las demandas del mercado o de mis clientes, y puede suponer una ventaja estratégica de negocio y/o que mis clientes perciban qué mi producto tiene una calidad más alta. Como no podemos quedarnos con una sola ventaja, veamos: ¿por qué merece la pena IaC?

¿Cuáles son las ventajas de implementarla?

• Reducción del riesgo humano y del esfuerzo: evitando tareas manuales creamos sistemas más robustos y confiables.
• Ganamos agilidad y velocidad realizando cambios más rápidos y generamos menos bloqueos. Impulsamos la entrega rápida de valor.
• Aumentamos la visibilidad. El acceso a lo que ocurre en tiempo presente o pasado está disponible de forma inmediata para el equipo.
• Integramos seguridad y calidad como parte del proceso de construcción de nuestros sistemas.
• Avanzamos hacia estrategias de integración y despliegue continuo.
• Paridad entre entornos y escalabilidad.
• Mejoramos la documentación, el propio código servirá para documentar procesos. Favorece el intercambio de conocimientos y aumenta el foco del equipo.
• Aumenta la autonomía de los equipos y los impulsa a ser independientes, algo que repercute en un aumento de la calidad de su trabajo.
• Mejora la velocidad para solucionar problemas.

Ahora que hemos visto las ventajas, pasemos a ver las tecnologías.

Dos grandes “patas”

Podemos dividir IaC en dos bloques:

• Infrastructure provisioning: Tiene que ver con definir los recursos que voy a crear, sus atributos y su relación con otros recursos. Por ejemplo: quiero una máquina ubuntu 20.04 con 4 cpus y 8 GB de RAM en la red de desarrollo.

• Configuración management: Tiene que ver con gestionar configuración (instalación de software, configuraciones, archivos, etc) en los sistemas administrados, de forma que escribo en código las tareas que quiero realizar y después las ejecuto sobre un scope de 1 o N máquinas. Por ejemplo: “quiero instalar y configurar docker en mi servidor1”.

¿Qué tecnologías existen?

Terraform, AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager, Pulumi, Ansible, Chef, Puppet, Salt y un sinfín de opciones. Dependiendo de cada cliente o proyecto tendremos que tomar algunas decisiones. ¿Cómo saber cuál conviene más a mi caso de uso? Repasemos algunos puntos importantes a tener en cuenta.

¿Qué tener en cuenta para elegir la tecnología apropiada?

• Validada, con recorrido y ampliamente utilizada. Necesitamos una tecnología robusta bien documentada y con una gran comunidad detrás que la respalde, que en algunos casos incluso son empresas como Hashicorp y RedHat.
• Open source. Siempre es un punto a favor y además no tendremos costes de licencias. Extender el código para un caso de uso específico siempre podrá considerarse como una opción.
• Vendor locking. Ser lo más agnóstico posible en cuanto al proveedor de cloud/virtualización es un punto importante, pues crea dificultades para nuestros equipos, cambios de contexto en cuanto al lenguaje y a la tecnología si nos vemos obligados a hacer uso de otro proveedor al que originalmente habíamos previsto y nuestra tecnología opera sólo con nuestro antiguo proveedor.
• El “lenguaje” que vamos a usar. Algo a tener en cuenta es el “lenguaje” que usaremos para nuestros desarrollos. Es interesante observar el background del equipo.
• Requisitos en host administrados (agentless). Algunas tecnologías de automatización requieren que tenga instalado software “cliente” en las máquinas que quiero administrar. Esto es una desventaja especialmente en entornos donde existen fuertes restricciones para instalar software. Además, tendré que administrar el ciclo de vida de ese software (versiones).

¿Cómo puedo ir más a fondo?

Si te interesan estos temas te invitamos a leer “Infrastructure as Code” de Kief Morris, de donde hemos extraído grandes lecciones para aplicar en nuestros proyectos.

Conclusión

Las tecnologías de IaC eliminan las barreras para hacer cambios en los sistemas de producción y esto genera nuevos desafíos. La mayoría de las organizaciones quieren acelerar su ritmo de cambio, mejorar la agilidad de sus procesos y hacer más robustos sus sistemas, pero no pueden permitirse ignorar los riesgos y la necesidad de gobernanza sobre ellos. Por ello y para avanzar en ésta línea, necesitamos establecer más controles automáticos.

¿En qué medida crees que debemos potenciar estas estrategías? Gracias por tu tiempo, te leemos en los comentarios.