Introducción al AWS CDK: Infraestructura como Código

Hola a todos. Gracias por asistir virtualmente a mi charla. Hoy voy a hablar sobre el AWS CDK, y el título de mi charla es Introducción al AWS CDK Infraestructura como Código. Entonces, supongo que la primera pregunta a responder CDK? Es una abreviatura de Kit de Desarrollo en la Nube. Es una herramienta específica de AWS en el pasado, el CDK no es lo mismo. El SDK de CDK puede mantener el estado de tu aplicación, lo que te permite actualizarla CDK en sí es bastante nuevo. Alcanzó la disponibilidad general AWS que aún no se admiten, AWS es bastante masivo. Y también es gratuito de usar, pero he incluido un asterisco AWS, se te facturará por esas cosas.

Cloud Native Computing Foundation que encuestó CDK realmente satisface a los desarrolladores donde están. AWS. Al usar una herramienta como esta, puedes escribir tu infraestructura y tus aplicaciones utilizando las mismas herramientas y lenguajes. Node.js, ya que permitía a los desarrolladores CDK también te ofrece una infraestructura probada. AWS CDK/assert. Se integra muy bien con Jest y las pruebas de instantáneas AWS a algo como Azure, es probable que sigas en es, ¿qué es el AWS para infraestructura como código. Es similar a herramientas como Terraform que quizás hayas utilizado en el pasado. Admite una variedad de lenguajes, por lo que puedes escribir tus aplicaciones en JavaScript, TypeScript, Python, Java y C Sharp. Creo que también hay planes para otros lenguajes en el futuro. La forma en que funciona internamente es que las clases de alto nivel de JavaScript o TypeScript se mapean a estas cosas llamadas plantillas de CloudFormation, de las cuales hablaré nuevamente en un par de minutos. Si has utilizado el SDK de AWS se utiliza para realizar llamadas de API simples, mientras que el y volver a implementarla sin tener que pasar por las mismas verificaciones que si estuvieras haciendo llamadas de API directas. El a mediados de 2019, por lo que todavía hay algunas características de ya que aquí porque si comienzas a usarlo para implementar cosas como instancias de EC2 u otros recursos de

Entonces, supongo que a continuación, podrías preguntarte, ¿por qué usaría esto? Como dije antes, hay muchas herramientas como esta, cosas como Terraform y demás. Voy a hacer referencia a un informe de la aproximadamente a 17,000 desarrolladores. Si no estás de acuerdo con estas citas, por favor no me disparen. Solo soy el mensajero. Pero JavaScript es el lenguaje de programación del lado del servidor más popular entre los desarrolladores nativos de la nube. Y el 62% de los desarrolladores nativos de la nube utilizan AWS como su proveedor de alojamiento en la nube. Entonces, el Ya hay muchos desarrolladores que están escribiendo aplicaciones en la nube con JavaScript y TypeScript y desplegándolas en Y eso siempre ha sido una de las ventajas de de frontend y backend utilizar el mismo lenguaje común. Y esto simplemente extiende eso aún más a tu implementación y operaciones. El Hay un módulo. Y la última cosa que quería mencionar es que realmente no debes preocuparte por el bloqueo del proveedor porque probablemente ya estás bloqueado. A menos que tengas la aplicación más trivial y puedas pasar de el mismo proveedor.

requiere cierto esfuerzo de importación. Por lo tanto, el CDK no te va a encerrar más de lo que ya estás. Y antes de profundizar demasiado en esto, quería mencionar algo que descubrí mientras investigaba el CDK y que me pareció interesante. Se llama JSII, que significa Interfaz de Interoperabilidad de JavaScript. Esta es la herramienta que se encuentra debajo del CDK y que le permite ser escrito en TypeScript, pero aún ser compatible con todos los otros lenguajes que mencioné anteriormente. Cuando leí sobre esto por primera vez, pensé que probablemente funcionaba generando código específico del lenguaje, pero en realidad se ejecuta en el tiempo de ejecución de node.js. Lo que hace es ejecutar tu código TypeScript y enviar la entrada y salida como JSON entre el proceso secundario de nodo y el proceso principal que está ejecutando tu aplicación. Por lo tanto, hay algunas uniones generadas que forman parte de la salida del CDK. Por lo tanto, puedes escribir tu código una vez y obtendrás la misma API en todos estos diferentes lenguajes. Desafortunadamente, esto conlleva un impacto en el rendimiento porque estás generando un proceso de nodo, estás interactuando con un proceso secundario en lugar de generar el código directamente. Pero pensé que eso era algo que

fue algo genial y quería compartirlo como parte de esta charla. Volviendo al punto general de esta charla. Como mencioné anteriormente, CloudFormation es un conocido servicio deAWS que básicamente te permite definir tu arquitectura, tus recursos que utilizarás en la nube como un archivo de plantilla JSON o YAML. Luego se puede implementar en el servicio CloudFormation. Se encargará de crear todos los recursos que necesites, como instancias o funciones lambda o cualquier otra cosa. Y en realidad puede gestionar grandes grupos de recursos como una única unidad, lo cual se llama una pila. Por lo tanto, se pueden crear pilas. Se pueden actualizar y modificar. También se pueden eliminar, y todo lo que sucede en ese grupo completo es una sola entidad. Esto simplifica mucho la sobrecarga de mantenimiento para los desarrolladores. Y como mencioné anteriormente, el hecho de que mantenga el estado entre tus implementaciones le permite ser mucho más poderoso que las llamadas individuales al SDK de AWS donde tendrías que gestionar todo ese estado tú mismo. Y dentro de CloudFormation, básicamente hay entradas y salidas para tu pila de CloudFormation. Las entradas se llaman parámetros. Y estos son útiles para pasar cosas como información sensible, o si estuvieras implementando un sitio web, tal vez cuál es el nombre de dominio para esa pila y cosas de ese tipo. Y también puede generar salidas. Entonces, si le dices que provisione un bucket de S3, es posible que no sepas de antemano cuál es el nombre de ese bucket. Por lo tanto, eso se puede utilizar como una salida, que luego puede ser importada por otra pila de CloudFormation. Por lo tanto, puedes ver que es componible y muy poderoso. Pero la mayor desventaja es que CloudFormation es muy verboso. Por lo tanto, mantener estos archivos JSON y YAML a mano puede ser bastante trabajo. Y es propenso a errores.

Entonces, el CDK vio el poder de CloudFormation e introdujo esta API sobre ella utilizando TypeScript. Y lo que hace es darte estos bloques de construcción llamados construcciones. Las construcciones son básicamente la forma en que construyes y compones aplicaciones de CDK. Y hay una variedad de diferentes tipos de construcciones en diferentes niveles. Por ejemplo, la construcción de nivel uno, estas son básicamente recursos de CloudFormation. CFN aquí significa CloudFormation en forma abreviada. Por ejemplo, hay una construcción de CDK llamada CloudFormation bucket. Y esto es simplemente, lo más básico que puedes obtener como envoltorio alrededor de CloudFormation. Pero luego hay construcciones de nivel dos

lleva eso a otro nivel para introducir una API basada en intenciones. Entonces, basándonos en el mismo ejemplo, en lugar de un bucket de CloudFormation, podrías usar un bucket de S3. Y esto tiene una API mucho más amigable para el usuario. Y finalmente, hay lo que se llaman patrones, que son aún más avanzados y pueden componer muchos componentes diferentes juntos. Estos realmente pueden acelerar tu productividad. Por ejemplo, en lugar de tener que crear funciones Lambda, conectarlas a una puerta de enlace de API y cosas así, puedes simplemente usar el patrón de API REST de Lambda. Y como dije, realmente puede acelerar la productividad. Y así es como funcionan estas aplicaciones: tomas tus diferentes construcciones y las compones en lo que se llama un árbol de construcciones. Y también vale la pena señalar que AWS proporciona una gran cantidad de construcciones desde su biblioteca, pero también es posible que los usuarios creen sus propias construcciones para adaptarse mejor a sus necesidades. Entonces, hay, supongo, dos tipos especiales de construcciones que vale la pena discutir un poco. Están nuestras aplicaciones y pilas. Entonces, la raíz del árbol de construcciones siempre va a ser un componente de aplicación. La razón por la que se llama una aplicación es porque las aplicaciones de CDK se refieren como aplicaciones. Como dije, esto siempre va a ser la raíz, pero luego las pilas son construcciones que se mapean a pilas de CloudFormation. Entonces mencioné que, en CloudFormation, los grupos de recursos se agrupan como una pila y esto es una especie de mapeo uno a uno. Entonces las aplicaciones contienen pilas. Puedes tener más de una en una sola aplicación, y luego las pilas son generalmente lo que contienen las otras construcciones. Una cosa que vale la pena señalar es que cada pila se configura mediante un entorno, y hablaré de eso ahora mismo. Entonces, un entorno es un ID de cuenta de AWS más una región donde se va a implementar la pila. Esto básicamente significa que este usuario está implementando en esta región en la nube. Y así, se debe proporcionar un entorno para cada región a la que intentes implementar, y para cada cuenta separada que pueda querer implementar tu pila. Si no especificas un entorno, entonces la pila se considera que es independiente del entorno, pero estos casos de uso son bastante limitados. Y luego, para proporcionar el entorno, si alguna vez has trabajado con alguna de las herramientas de AWS antes, hay varias formas de hacer esto. En el propio código, puedes pasar valores al constructor de la pila, pero también puedes pasar una bandera de perfil desde la línea de comandos o especificar diferentes variables de entorno, y el código automáticamente las recogerá y sabrá dónde implementar tus cosas. También puedes configurar tu perfil de AWS para tener un entorno predeterminado. Pero eso es más para casos de uso de desarrollo local. Con todo eso, creo que podemos generar nuestra primera aplicación de CDK. He agregado un comando de línea de comandos simple aquí usando mpx, por lo que no tienes que instalar nada todavía. mpx aws-cdk, ese es el nombre del módulo. init, app, y luego pasamos el lenguaje. Queremos usar JavaScript aquí.

pero puedes utilizar cualquiera de los otros lenguajes compatibles. Y así se creará un esqueleto completo de la aplicación para ti. Una nota es que debes ejecutar esto desde dentro de un directorio vacío para que no sobrescriba accidentalmente cualquier cosa que pueda existir. Y así se crea una carpeta bin, y puedes ejecutar este archivo directamente. Puedes ver el pequeño shebang en la parte superior del código aquí que incluyen la mayoría de los binarios de node. Entonces, lo que hace es importar una pila de prueba que también se generó para ti, instanciar tu aplicación con el nuevo constructor cdk.app, y luego simplemente crear una nueva pila de prueba, y dentro de la pila de prueba puedes ver que pasa la aplicación como el primer argumento. Así es como el árbol de construcciones realiza un seguimiento de qué construcciones son hijos de otras construcciones. Y luego vamos a llamar a esta pila de prueba, así que eso es lo que está ahí como segunda opción. Si miramos la pila en sí, puedes ver que este es el código que se generó. Dejé algunos de los comentarios y otras cosas que se generaron automáticamente, pero en futuros ejemplos los eliminaré para ahorrar espacio. Lo primero que hacemos es importar el CDK en sí, y luego creamos una clase de pila de prueba, que extiende la clase base de la pila CDK. El constructor de una clase toma un alcance, un ID y props. El alcance es la construcción principal, como mencioné antes. La idea lógica de la construcción va a ser cuando sintetizamos y desplegamos estas aplicaciones. Y los props son un mapa opcional que se puede pasar y se utiliza para definir otras propiedades de tu construcción. Entonces, si queremos añadir más construcciones, podríamos hacer algo como esto. NPM install --save AWS CDK/AWS EC2. Esto básicamente instalará las construcciones de CDK para el servicio EC2. En este ejemplo sencillo, estoy añadiendo una VPC a nuestra pila. La razón por la que hago esto es porque las VPC se pueden desplegar sin ningún cargo adicional. Así que si quieres experimentar con esto y desplegarlo, deberías poder ejecutar esto sin incurrir en ningún cargo.

A continuación, quiero hablar sobre cómo se sintetizan y despliegan estas aplicaciones. Puedes ver el flujo de trabajo general aquí. Verás cdk-cli en la parte superior. cdk-deploy es uno de los comandos de la CLI. Hablaré sobre cuáles son algunos de los otros más adelante. Y lo que hace es leer el código fuente de tu aplicación. Pasa por lo que se llama la fase de construcción, donde se ejecuta el código del usuario y se ejecuta toda la cadena de constructores, por lo que básicamente se está construyendo el árbol de construcciones. Las fases de preparación y validación son ganchos disponibles para las construcciones, pero generalmente no son necesarios y a veces incluso se desaconsejan. Y luego viene la fase de síntesis, que genera algo llamado un cloud assembly. El cloud assembly será tu plantilla de cloud formation, así como cualquier otro artefacto de despliegue que se necesite para desplegar tu aplicación en la cloud.

Y hablaré sobre qué son esos otros artefactos de despliegue en un momento. Y luego el despliegue tomará tu conjunto de nubes y cargará cualquier cosa que necesite ser cargada a la nube y comenzará un despliegue de formación en la nube. Y una vez que eso tenga éxito, tendrás una aplicación CDK que está realmente desplegada en la nube. En realidad, puedes hacer el paso de síntesis como un paso separado sin necesidad de desplegarlo, lo cual es bueno para pruebas locales y pruebas unitarias. Entonces, harías eso a través del comando MPX AWS CDK synth y luego el nombre de tu pila. En este caso, la pila de prueba, esto generará, traducirá tu aplicación CDK en una plantilla de formación en la nube. Generará cualquier artefacto de despliegue, como imágenes de Docker, si estás desplegando alguna función lambda, las empaquetará para ti. Y luego escribirá todo tanto en las salidas estándar, ya que esto es solo una síntesis y no un despliegue. Pero también creará tu directorio cdk.out, que es donde se almacena todo antes de ser desplegado. Y luego puedes ver a la derecha aquí, en realidad he capturado cómo se ve la plantilla de formación en la nube. Y puedes ver que ocupa toda la altura de la diapositiva y es muy ilegible. Y eso se basa en una aplicación CDK que tenía aproximadamente una docena de líneas de JavaScript. Así que puedes ver de dónde viene la mayor verbosidad con la formación en la nube, así como

el poder expresivo de cdk. A continuación, quería hablar sobre los activos y la inicialización. Entonces cualquier archivo o directorio local que deba cargarse en S3 o cualquier imagen de Docker local que deba cargarse en el Registro de Contenedores Elásticos se conocen como activos. Si tu aplicación utiliza alguno de estos activos, entonces tendrás que hacer algo llamado inicialización, que es algo que se debe hacer por entorno. Por usuario y combinación de región. También creará una pila adicional de formación en la nube para ti llamada cdk-toolkit. Y consta de un bucket de S3 y un conjunto de recursos IAM para implementar los activos en la nube. Una cosa a tener en cuenta es que es probable que se te cobre por esto porque estarás almacenando activos en AWS. Así que quería ver un ejemplo más realista ahora donde implementaremos un sitio estático de S3. He incluido un asterisco aquí porque nuevamente se te cobrará por AWS si ejecutas esto. He creado una nueva pila aquí llamada pila del sitio web que extiende la clase de pila CDK. Y luego dentro estoy creando un nuevo bucket de S3. Así que voy a llamar a mi bucket bucket del sitio web. Voy a hacer que index.html sea la página de inicio de mi sitio que estoy implementando y voy a otorgar acceso de lectura pública al mundo para que cualquiera pueda ver mi sitio. Y luego, para implementarlo, usaré el constructo de implementación de bucket de implementación de S3 para adjuntarlo a la pila. Lo llamaré implementación de mi sitio web. Las fuentes vendrán de un directorio local al que llamo www que en realidad creará activos como mencioné en la diapositiva anterior, esa es la parte por la que se te cobrará y luego cargará todo en el bucket que acabamos de crear bucket del sitio web. Algo que vale la pena señalar aquí, sabes que este es un ejemplo pequeño porque tiene que caber en una diapositiva, pero puedes llevar esto más lejos y agregar cosas como DNS o CDN para crear un sitio estático agradable para ti mismo. Entonces, para implementar el sitio, diríamos mpx awscdk deploy pila del sitio web y luego realmente voy a pasar mi perfil de aws desde la línea de comandos para que sepa a qué entorno implementar. Pero la primera vez que ejecuto esto, veré el siguiente error que dice que esta pila utiliza activos, por lo que la pila de herramientas debe implementarse en el entorno. Entonces, lo que eso significa es que tengo que inicializar este entorno primero y puedes ver a continuación que he agregado el mpx awscdk bootstrap y luego he pasado mi perfil que creará la infraestructura de inicialización de la que hablé antes. Luego puedo volver a ejecutar la misma implementación y todo debería funcionar según lo planeado esta vez. Entonces, si quieres ver cómo se ven esos recursos implementados en la parte superior izquierda aquí tengo la consola de CloudFormation que muestra las pilas de la aplicación y de inicialización. La esquina superior derecha es la consola de S3 que muestra los buckets de la aplicación y de inicialización. La parte inferior izquierda es el bucket de la aplicación que contiene los activos estáticos y la parte inferior derecha es el sitio implementado y en funcionamiento en producción. Como dije, si quieres hacer esto un poco más elegante podrías agregar algo como DNS en el CDN para tener una URL más amigable para el usuario allí. Y luego, para limpiar, usarás CDK destroy pila del sitio web. También recomiendo que ingreses a la consola web de AWS y explores S3 y CloudFormation para ver que todos los recursos se hayan limpiado. He vinculado a un problema de CDK a continuación donde la inicialización no siempre se limpia a sí misma. Quería proporcionarte aquí los comandos que puedes usar para limpiar. O simplemente haz clic en la consola web y deberías poder hacer la misma limpieza manualmente. Y luego quería concluir hablando sobre la CLI. Estos son básicamente los comandos que usamos para hacer lo mismo

despliegue. Puedes instalar el CDK localmente. Si haces eso, se conocerá como CDK y no como AWS CDK. Eso es algo a tener en cuenta. También puedes instalarlo globalmente con la bandera -G, pero realmente no lo recomiendo. Las dependencias globales generalmente no son lo mejor. Por lo tanto, recomiendo agregarlo a tu package JSON y llamarlo desde uno de tus scripts de NPM.

También hay otros comandos útiles aquí que no mencioné. CDK-LS enumerará las pilas que están en la aplicación. Diff comparará la pila con la versión implementada o la plantilla local de CloudFormation. Metadata puede mostrar los metadatos que se han adjuntado a una pila. De manera similar, puedes pasar pares clave-valor llamados contexto de tiempo de ejecución a tu aplicación usando CDK context. Hay un comando doctor que puede analizar tu proyecto y vincularlo para posibles problemas. Y luego CDK-doc se puede usar para abrir la documentación oficial en el navegador. Es una especie de atajo. Y finalmente, quería incluir algunos recursos adicionales aquí. El primer enlace es la documentación oficial, el segundo enlace es el código fuente de CDK, y los enlaces restantes son una combinación de recursos creados por AWS y la comunidad para aprender el CDK y proporcionar ejemplos de referencia. Así que realmente puedes comenzar y ponerlo en funcionamiento bastante rápido. Eso es todo lo que tenía. Gracias nuevamente por venir a mi charla y que tengan un buen día a todos. Colin, bienvenido. Bienvenido a tu sesión de preguntas y respuestas aquí. Antes que nada, echemos un vistazo a la encuesta. Le preguntamos a la gente, tú les preguntaste, ¿has usado el AWS Cloud Development Kit? Y la mayoría de las personas dijo que no. Bueno, ¿por qué crees que es eso? Me gustaría escuchar tu comentario al respecto. Realmente no es sorprendente en absoluto. Como dije, es bastante nuevo. Recién se volvió apto para producción hace un par de años. Sin embargo, creo que realmente está empezando a ganar popularidad, así que espero difundir la buena palabra del CDK y espero que algunos desarrolladores de JavaScript tengan la oportunidad de probarlo, ponerlo a prueba. Siento que realmente derriba una de las últimas barreras que existen para que los desarrolladores de JavaScript puedan

hacer todo el stack ellos mismos. Exactamente, exactamente. Y todavía recuerdo el día cuando vi el primer correo electrónico sobre CDK dentro de la empresa. Alguien simplemente envió un correo electrónico, hey, tengo esta gran idea, ¿qué tal si hacemos esto? Una cosa maravillosa. Así que creo que el crecimiento del uso de CDK en AWS crecerá con el tiempo porque simplemente simplifica las cosas. Uno de los puntos que mencionaste en tu charla fue que quita mucho esfuerzo de escribir una infraestructura declarativa como código a una forma más sensata y predeterminada de escribir infraestructura como código. Entonces, ¿qué te hace usar CDK en lugar de CloudFormation, por ejemplo? CloudFormation, para mí, es genial porque te brinda la capacidad de implementar y maneja las actualizaciones y todo eso. Es solo mucho texto para administrar y sudar, y es propenso a errores. Para mí, el CDK fue agradable porque estoy escribiendo JavaScript, que ya estoy haciendo mientras aplico. Si hay un error de sintaxis, es un error de sintaxis familiar en lugar de tratar de buscar en un archivo YAML o JSON grande. Es mucho más compacto. En un lado, mostré en el lado derecho, era como todo el texto de CloudFormation y no se podía leer en absoluto en comparación con una docena de líneas de CDK JavaScript. Para mí, eso es una gran ventaja.

Estoy de acuerdo. A veces, si quieres hacer algo realmente rápido, como crear una VPC, en CDK, es una sola línea de código. En CloudFormation, son 87 líneas de código.

Pasemos a algunas de las preguntas que tenemos del público. Una pregunta de Lara. ¿Es posible usar el Cloud Development Kit para automatizar rollbacks basados en condiciones personalizadas? Por ejemplo, pruebas de humo fallidas o algo así. Esa es una buena pregunta. No lo sé de memoria. Maneja rollbacks, pero no sé si los maneja en función de condiciones personalizadas o no. Eso es algo que tendría que imaginar. Entonces, permíteme intentar responder esta pregunta desde mi experiencia. Si estás implementando tu Cloud Development Kit a través de un pipeline de CI CD, definitivamente puedes fallarlo. Si algo sucede, simplemente puedes activar un rollback fallido en el lado de CloudFormation, porque como dice Colin, CDK utiliza CloudFormation para muchas de sus partes. Entonces, en esencia, sí.

De acuerdo. Pregunta. Y estas son preguntas muy comunes que también escucho cuando hablo de esto, una pregunta de Marc. ¿Existen beneficios al usar el Cloud Development Kit sobre el framework serverless o el framework serverless.com? Entonces, creo que hay compensaciones, como con todo. Con el CDK, es un ciudadano de primera clase

ciudadano en AWS. Entonces, sabes, está construido por ingenieros de AWS, respaldado por ingenieros de AWS. Se garantiza que funcionará allí. El framework serverless, ya sabes, puede funcionar un poco mejor con otras nubes. Pero, ya sabes, eso es un poco por diseño. Entonces, supongo que, en mi opinión, si estás implementando en AWS, probablemente usar las herramientas oficiales de AWS sea el mejor escenario posible.

Estoy de acuerdo. Un punto justo. Ya sabes, el framework serverless tiene sus propios beneficios, especialmente para aplicaciones serverless. También tienes SAM en AWS, que es una especie de transformación de CloudFormation. Pero, CDK, nuevamente, como una de las cosas que tiene CDK, y lo demuestras en tu charla, es que tiene esta capacidad de utilizar un lenguaje de programación nativo para construir cosas. Entonces, si eres un desarrollador de JavaScript, es mucho más fácil escribir esto que tratar de descifrar algún JSON o YAML, en este caso. De acuerdo, tenemos más preguntas. Una de AO. Para aquellos de nosotros que ya estamos construyendo nuestra infraestructura en CloudFormation, ¿es posible importar recursos existentes, como una database de producción o algo estático, al Cloud Development Kit? Sí, deberías poder hacer eso. Así que estoy trabajando en un proyecto de AWS bastante grande en este momento que se basa en CloudFormation y puedes ir migrando partes de él al CDK poco a poco. Entonces, no necesariamente tienes que hacer la transición completa de golpe, si eso es lo que estás preguntando, si tiene sentido.

Correcto, entonces estás diciendo que potencialmente no tienes que transferir todo tu proyecto al CDK de una vez, ya sabes, puedes dejar algunas cosas y otras formas de aprovisionar cosas. Correcto. Definitivamente no estoy abogando por, ya sabes, si tienes una solución funcional, simplemente desechar todo y tratar de reestructurarlo solo porque, probablemente terminarás con más dolores de cabeza que beneficios. Sí, ya sabes, una de las cosas, una de las infinitas sabidurías que escucho es que el mejor framework/lenguaje de programación es aquel en el que eres bueno. Entonces eso es lo que deberías usar. Ok, tenemos una pregunta de SB. ¿Por qué CDK se basa tanto en clases en lugar de en constructos más habituales en JavaScript como funciones? Es simplemente una forma de ver la nube como una colección de objetos que interactúan entre sí a través de diferentes propiedades. Por ejemplo, tienes una función lambda, creo que es fácil pensar en eso como una clase, tienes una instancia de una lambda, tiene propiedades específicas, como un ARN y cosas por el estilo. Mientras que si intentaras hacerlo más funcional, creo que el código sería un poco

menos limpio de esa manera. Entendido. Entendido. De acuerdo. De acuerdo. Sí. Como utilizo mi CDK principalmente en TypeScript o en Python, pero no soy un gran desarrollador. Solo lo uso como una utilidad, así que ni siquiera sabría cómo responder a esta pregunta. Pero hablando de lenguajes de programación y la capacidad de CDK para utilizar lenguajes de programación genéricos, ¿hay alguna forma de probar si realmente implementamos cosas? Porque hablamos un poco antes en las charlas rápidas de que las pruebas son realmente importantes. ¿Podemos hacer lo mismo con el código de CDK? ¿Hay alguna forma de probar el código antes de hacerlo?

Sí. Entonces, CDK fue diseñado de tal manera que se integra muy bien con Jest y tiene su propia biblioteca de aserciones incorporada. Creo que lo mencioné en mis diapositivas. Básicamente, puedes tomar un stack de CDK y decir expect stack to, y luego hay algunas funciones auxiliares. Por ejemplo, incluir un recurso específico o incluir este conjunto de recursos o hacer coincidir este patrón. Hay todo tipo de funciones de utilidad útiles con las que puedes realizar pruebas unitarias en tu stack antes de intentar implementarlo y luego intentar depurarlo en la cloud. Cuanto más puedas hacer localmente, mejor.

Sí. Básicamente, escribir tus pruebas unitarias para CDK y tener expectativas establecidas. Recuerdo que una vez, hace mucho tiempo, hice lo mismo con Jest. Jest es este marco para pruebas. En lugar de hacer aserciones, en realidad usé la función de instantánea. Entonces también puedes hacer instantáneas de lo que quieres que suceda, y si algo cambia, simplemente no funciona. Excelente. Creo que CDK también tiene funciones para integrarse con instantáneas. Puedes decir que la instantánea debería significar algo. De acuerdo. Excelente. Ahí lo tienes.

Última pregunta para ti. Tenemos un 71% de personas aquí que respondieron que no han probado CDK o no lo usan. ¿Cuál es tu consejo para los usuarios novatos de CDK? Para alguien que después de tu charla decida, ya sabes qué, voy a hacer algo en CDK. ¿Cuál es tu consejo para ellos? Mi consejo para ellos sería, ya sabes, si ya tienes una configuración existente, puedes probar pequeñas partes de CDK y ver si coincide con lo que ya tienes. Si tienes la suerte de estar haciendo un desarrollo desde cero, entonces hay muchos tutoriales disponibles y demás. Puedes seguir esos y asegurarte de que básicamente lo estás entendiendo

hacerlo bien desde el principio. Pero tómate tu tiempo. En realidad, es muy sencillo. Siempre y cuando comprendas el lenguaje en el que estás programando y entiendas lo que estás intentando construir en AWS, creo que encontrarás que la fricción es bastante baja. Si no estás completamente seguro de lo que quieres construir en AWS primero, creo que sería útil obtener esa comprensión básica para entender qué es una función Lambda o qué tipo de instancia EC2 deseas. Algo así. Sí. Excelente. Muchas gracias, Colin. Aprecio todas las preguntas, todas las respuestas a las preguntas y a todos, agradezco sus preguntas. Muchas gracias por tu charla. Fue increíble y muchas gracias por tu tiempo. Gracias. Que tengas un buen día.