Cloud Development Kit (CDK) — 101
Resumen
En este artículo, hemos explorado los conceptos de Infraestructura como código, CloudFormation y CDK profundizando en los conceptos fundamentales para poder empezar a trabajar con el framework de CDK. En otros artículos exploraremos y experimentaremos las opciones que nos ofrece CDK.
El concepto de infraestructura tecnológica ha tenido una fuerte evolución en los últimos años. Ahora vemos cómo muchas empresas ya empezaron (o están en el proceso de empezar) a migrar su datacenter on premise hacia proveedores de nube. Allí, encuentran, entre otras cosas, precios más flexibles, escalabilidad, aprovisionamiento veloz y diversas opciones para fortalecer su seguridad.
Esta transición nos trae muchas preguntas y, entre ellas, una bastante importante es, ¿cómo vamos a administrar ahora? Recordemos que, en los servidores físicos propios, si requerías un entorno, debías pedirlo a tu administrador de confianza y él podría tardar entre 2 y 3 semanas para entregarte el ambiente y con probabilidad de que no fuera lo que buscabas. Esto consumía mucho tiempo, dinero y paciencia.
Sin embargo, en nube es diferente, pues es posible desplegar un ambiente de desarrollo en menos de 5 minutos y unos cuantos clics, desde un frontend hasta una base de datos. Ahora bien, si les dijera que, además de eso, un entorno cloud tiene la capacidad de automatizar estos despliegues de manera ordenada, ¿me creerían?
De esta manera es como llegamos a la infraestructura como código (IaC), que nos hace posible convertir infraestructura compleja en un elemento replicable y maleable.
Así, llegados a este punto, en este artículo hablaremos de infraestructura como código, específicamente de las nuevas tendencias de la mano de CDK que para resumir es un tipo de IaC con paradigma diferente.
Infrastructure as a Code (IaC)
Antes de comenzar a hablar de CDK es necesario realizar una revisión rápida al concepto de IaC (Infrastructure as a Code).
¿Qué es?
Cuando hablamos de IaC nos referimos a un proceso o paradigma que permite aprovisionar y administrar infraestructura (redes, máquinas virtuales, balanceadores de carga, etc) a través de código.
¿Por qué?
Las principales razones por las cuales deberíamos utilizar IaC en nuestros proyectos son:
- Automatizar procesos
- Homologación de ambientes
- Replicación de entornos
- Cambios controlados
- Fácil escalabilidad
- Integración con cualquier metodología de DevOps
- Generación de flujos de trabajo flexible
- Eliminación de brechas entre equipos
- Aumento de la velocidad de desarrollo
- Disponibilidad de ambientes de desarrollo flexible
AWS CloudFormation
¿Qué es?
CloudFormation es el servicio de AWS que permite modelar, aprovisionar y administrar una serie de recursos de infraestructura en la nube de una forma sencilla y ordenada (IaC). Es importante mencionar que CloudFormation no sólo funciona para servicios de AWS, sino también para algunos terceros.
AWS Cloudformation acepta el uso de CloudFormation Templates, Terraform o AWS CDK para la definición de IaC.
AWS CloudFormation — Templates
Un CloudFormation Template es donde definimos/declaramos uno o varios recursos. Para ser más concretos, es una herramienta de IaC la cual usa un paradigma declarativo, es decir, en dicho código estaremos llenando una plantilla definiendo explícitamente las especificaciones de la infraestructura a desplegar.
CDK
¿Qué es?
Cloud Development Kit (CDK) es un framework de desarrollo de software que permite definir IaC con un paradigma imperativo y aprovisionarla a través de AWS CloudFormation.
CDK — CDK APP — ¿Qué es?
Es la representación lógica de nuestra infraestructura. Es decir, cada vez que deseamos hacer uso de CDK, iniciamos por crear una CDK APP. Al estar escrita en un lenguaje de programación, posee todos sus beneficios, tales como:
- Estructuras de datos
- Herencia
- Modularidad
- Polimorfismo
- Patrones de diseño, entre otros.
Principales lenguajes soportados por CDK
• TypeScript (Main)
• Java
• .NET
• Python
De los anteriores, para seguir con esta introducción a CDK, vamos a elegir TypeScript debido a que es el lenguaje fuente utilizado por AWS para desarrollar la herramienta.
Partes de CDK — CDK APP
Para poder entender de manera efectiva cómo funciona una app de CDK en alto nivel, procederemos a dividir la aplicación en unidades lógicas y explicarlas una a una.
1. Construct
Un construct se puede entender como la representación de uno o más componentes de infraestructura. Por ejemplo, un construct puede ser desde un bucket de S3, hasta el conjunto de recursos que conforman un sitio web estático con CloudFront. A su vez, un construct es la unidad mínima de CDK, es decir, el componente más básico.
Nota: A nivel de código un construct es un objeto.
Todos los constructs se inicializan de la siguiente manera:
new aws_s3.Bucket(scope, logicalId, props)Donde:
• Scope: Es el contexto de la aplicación donde queremos que se aloje el construct. (Estos contextos se manejan a partir de constructs de orden mayor)
• Id: Es el logicalId del construct, esta variable define cómo se va a llamar el recurso en CloudFormation.
• Props: Corresponde al conjunto de características del construct.
Tipos o niveles de construct
Explorando la documentación oficial de CDK, podremos observar que existen demasiados constructs y equivalente a la cantidad de recursos que podemos desplegar a través de CloudFormation, de eso hablaremos más adelante.
No obstante, estos constructs pueden tener 3 niveles o tipos. Estos son:
• CFN Resources (Bajo nivel) L1: requiere en su configuración (props), la definición explícita de cada propiedad (No tiene abstracciones o configuraciones automáticas desde CDK)
• AWS Constructs (Alto Nivel) L2: proporcionan valores predeterminados, un modelo estándar y lógica de programación preconfigurada para su uso (Se pueden considerar como abstracciones avanzadas de los CFN Resources diseñadas para CDK)
• Patrones (Alto nivel+) L3: como su nombre lo dice, abarca patrones de infraestructura, es decir, agrupaciones de recursos o de constructs que cumplen con un objetivo común. Ejemplo: aws-apigateway, LambdaRestAPI, aws-S3Cloudfront…
Para estos tipos o niveles, es posible desarrollar constructs tipo patrón debido al nivel de personalización que ofrece CDK.
2. Stack
Se podría definir como la unidad desplegable. Se asemeja al Stack de CloudFormation, donde todos los recursos definidos (constructs) dentro de él, son desplegados como una unidad. El Stack se ve de la siguiente manera en la CDK app:
public class MyStack extends Stack {
public MyStack(scope: Construct, id: string, props?: StackProps){
super(scope, id, props);
// Tus recursos (constructs) van aqui…
}
}3. App
Este es el lugar de la aplicación de CDK donde definimos los stacks que se desplegarán y desde donde se controlan todas las acciones sobre los mismos.
App app = new App();
new MyStack(app, “hello-cdk”);¿Cómo Funciona CDK — CDK APP?
Ya hablamos de qué es y qué partes tiene una app de CDK. Ahora, es importante entender las 5 fases por las que pasará una aplicación construida con esta herramienta:
1. Construcción: En esta fase se ejecuta la mayoría del código y se instancian todos los constructs.
2. Preparación: Después de instanciar cada construct, ejecutamos el método prepare(), esto prepara todo para antes de ejecutar el synth, del cual hablaremos más adelante.
3. Validación: Posterior al prepare, se ejecuta el validate(), con este método se verifica que los atributos asignados a los construcs instanciados sean coherentes.
4. Síntesis (synth): Fase final de la ejecución de la CDK APP app.synth(), en esta fase se genera el template de CloudFormation (es la primera parte de la magia).
5. Despliegue (deploy): Empaqueta y sube los assets generados en el paso anterior a un bucket de S3 para su posterior ejecución en CloudFormation.
Pros y Contras de CDK
A parte de los beneficios nombrados anteriormente, CDK también posee las siguientes ventajas:
- Es open source
- Es infraestructura como código
- Es un paradigma imperativo
- Acelera procesos
- Simplifica la ejecución
- Automatiza
- Tiene una comunidad activa
- Tiene un framework en constante crecimiento
Por otro lado, las limitaciones de CDK están sujetas a las características de AWS CloudFormation. Estas son:
Por cuenta
- 200 stacks
Por stack
- 500 recursos
- 200 parámetros
- 200 mappings
- 200 outputs
Por recurso
- 255 caracteres por nombre
