1. Introducción a Infrastructure as Code (IaC)

IaC es un modo de trabajo que nos permite definir mediante código, los recursos que componen nuestra infraestructura y la relación que existe entre ellos. 

Gestionar la infraestructura como si fueran piezas de código fuente es uno de los principios fundamentales de la filosofía DevOps ya que permite aprovechar las buenas prácticas asociadas al diseño de software y refinadas durante años de desarrollo, para aplicarlas a la provisión y gestión de la infraestructura. De este modo, podemos expresar nuestra infraestructura mediante ficheros de código que serán reutilizables, se podrán compartir y versionar, garantizando que los entornos creados sean más robustos, fiables, fáciles de mantener y de gestionar y, sobre todo, que sean repetibles. 

2. Modelo Declarativo vs Modelo Imperativo

La diferencia principal entre el modelo declarativo y el modelo imperativo es poder diferenciar entre el ‘Qué’ y el ‘Cómo’.
En el paradigma declarativo, se pone el foco en el objetivo final, dando menos importancia al flujo del programa y la lógica subyacente. Un ejemplo sería “Quiero tres instancias”.
En el paradigma imperativo, se construyen estructuras de control y se da importancia a la lógica. Por ejemplo, “Construye una instancia y repite hasta que haya tres”.

Al no tener una lógica subyacente en el código, los script declarativos (que en el caso de la Infraestructura como código son más bien archivos de texto con un formato específico en YAML o JSON) tienden a ser más largos pero también más fáciles de leer y por tanto de mantener y construir.

Por el contrario, los scripts imperativos no son necesariamente difíciles de escribir, pero tener una lógica incrustada hace que mantenerlos caiga en la misma categoría que mantener software, es necesario prestar atención a las interacciones entre componentes del programa y, en general, resulta algo más tedioso realizar su mantenimiento.

3. CloudFormation

Es un servicio nativo que automatiza el despliegue de recursos en AWS, usa plantillas para declarar los recursos y es la herramienta de IaC propia de AWS. Es la vía recomendada del proveedor, aunque no es la única que se puede usar, para aprovisionar infraestructura en distintos entornos o cuentas y gestionar los recursos. CloudFormation juega un papel importante ayudándonos a distribuir las soluciones sin importar el entorno, cuenta o la región. 

Aprender CloudFormation no es complicado, solo hay que entender algunos conceptos básicos del servicio (Templates, Stacks, Change Sets) y adaptarnos a la sintaxis de los ficheros de configuración. Dominando esto, se pueden desplegar en muy poco tiempo soluciones complejas, así como replicarlas y distribuirlas. Es un servicio gratuito y solo se incurren en gastos con los servicios y recursos desplegados, por lo que es una herramienta que gestiona nuestra infraestructura sin cargo alguno por el servicio como tal.

Roll backs automáticos, si por alguna razón no es posible desplegar la infraestructura se presenta alguna inconsistencia en el proceso de despliegue, CloudFormation intenta deshacer los cambios que hayan podido producirse durante la ejecución y dejar la infraestructura como estaba antes del despliegue, incluyendo la verificación de dependencia entre recursos antes del borrado o actualización.

Detección de desviaciones (Drift) entre lo que queremos desplegar y lo que actualmente tenemos desplegado, muy útil para detectar casos de click ops en un entorno, cosa que es bastante difícil de seguir si la infraestructura es grande.

4. CDK

CDK usa un lenguaje de programación para abstraernos de los típicos ficheros de configuración, escribimos menos código y hacemos lo mismo o más usando el lenguaje de preferencia para nuestra IaC ya sea TypeScript, Python o JavaScript. Al escribir menos código el mantenimiento se reduce, es más fácil compartirlo y sobre todo entenderlo rápidamente. Ejemplo de esto puede ser la creación de recursos de networking para una cuenta o el mantenimiento de un API en Api Gateway con muchos endpoints.

El factor común de todos los lenguajes de programación soportados por CDK es que se llevan excelentemente con la programación orientada a objetos, esto permite hacer abstracciones y hereda beneficios de este paradigma, no solo la portabilidad y la reutilización de nuestro código si no poder crear piezas de arquitectura que abstraiga de mucha complejidad al usuario de la misma, todo esto sin comprometer la flexibilidad y configuración que se requiera, también pudiendo extender fácilmente a funcionalidades específicas bajo demanda sin mucho esfuerzo.

Confieso que cuando conocí CloudFormation me gustó y me adapté rápido, me ayudó y disfrute de su uso pero cuando conocí CDK luego de pasar la primera barrera de entrada me quedé con CDK sin dudarlo, puedo hacer lo mismo que CloudFormation más rápido y mejor, usar loops y condicionales como también llamar a la API de AWS cuando se sintetiza el stack para crear recursos dinámicos, pero lo que más me gustó es que no tengo que estar pivotando en la documentación para crear un recurso ya que todo está incluido en la librería. Cualquier editor / IDE moderno puede mirar dentro de la librería para ver todo lo que necesito para usarla, aparte el autocompletado es un plus muy grande y si lo juntamos con el tipado que nos ayuda saber el tipo de argumento esperado hace que apenas tengas que salir del entorno del editor para buscar información. [Enrique Alonso]

Empaquetar la solución o producto de infraestructura y hacer un delivery que pueda usar cualquiera con muy poca configuración se logra mediante los Constructs de CDK. Se utilizan para crear recursos como un Bucket de S3 o una infraestructura entera como una API con persistencia y una distribución de Cloudfront. Podemos crear nuestros propios Constructs según requerimientos y así aplicar el concepto de DRY ya que si una solución se repite mucho podemos empaquetarla y distribuirla en los distintos equipos de trabajo.

CDK incluye una librería para testeo con el que se pueden hacer varias aserciones del código, sin embargo está preparado para que pueda ser testeado y según qué lenguaje se utilice, se combine con la suite de tests de turno. Con pytest puedes extender las funcionalidades de la librería interna de tests de CDK y tener casos más complejos de pruebas, en realidad la recomendación de AWS es que los tests se mantengan simples y evaluar comportamientos sencillos del código, pero a medida que los Stacks crecen y metemos complejidad lo ideal es que los tests nos indiquen si rompimos algo con nuestros cambios y poder remediarlo antes de probar en un entorno real.

5. Inconvenientes

  • Tanto CDK como CloudFormation son las herramientas propias de AWS para crear IaC para su plataforma, por lo que tendremos una integración óptima y un gran soporte, pero no es trasladable fuera de AWS.
  • Librería en constante desarrollo: Actualmente los cambios de versión de la librería son constantes y según como se mire puede ser un problema. Esto es algo normal, ambos servicios están en desarrollo y son riesgos que hay que sopesar. Si vemos el vaso medio lleno podemos alegar que están añadiendo nuevas funcionalidades o corrigiendo los problemas de las versiones anteriores, tanto AWS como la comunidad están trabajando para que sea el estándar para la IaC en AWS. 

Authors

  • Cloud Architect at Keepler: "I'm interested in IT strategy with a focus on Governance and Architecture as well as the ideas behind them. But in my heart I'm an engineer who loves building stuff. When I'm not in front of a computer, I enjoy music and teaching."

  • Cloud Engineer en Keepler Data Tech: “I'm a curious developer, I like to automate and solve problems, coding and learn something new every day. I'm a fan of good practices and I try to apply them as much as I can, I love APIs, communicating services between them and if it can be serverless, much better.”