Introducción al AWS CDK: Infraestructura como Node

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 a la infraestructura como código de AWS CDK. Entonces, supongo que la primera pregunta a responder es, ¿qué es el CDK? Es una abreviatura de Cloud Development Kit. Es una herramienta específica de AWS para infraestructura como código. Es similar a herramientas como Terraform que es posible que hayas usado en el pasado. Admite una variedad de lenguajes para que puedas escribir tus aplicaciones en JavaScript, TypeScript, Python, Java y C sharp. Creo que también hay planes para otros lenguajes en el futuro. Y 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 que hablaré nuevamente en un par de minutos. Si has usado el CD o SDK deAWS en el pasado, el CDK no es lo mismo. El SDK de AWS se utiliza para hacer llamadas simples a la API, mientras que el CDK es capaz de mantener el estado de tu aplicación, lo que te permite actualizarlo y volver a implementarlo sin tener que pasar por las mismas verificaciones que si estuvieras haciendo llamadas directas a la API. El CDK en sí es bastante nuevo. Alcanzó la disponibilidad general a mediados de 2019. Por lo tanto, todavía hay algunas características deAWS que no están compatibles, ya que AWS es bastante masivo. Y además es gratuito de usar, pero he incluido un asterisco aquí porque si comienzas a usarlo para implementar cosas como instancias EC2 u otrosAWS

recursos, se te cobrará por esas cosas. Entonces, supongo que a continuación, podrías estar preguntando por qué usaría esto. Como dije antes, hay muchas herramientas como esta, cosas como Terraform y demás. Así que voy a presentar un informe de la Cloud Native Computing Foundation que encuestó aproximadamente a 17,000 desarrolladores. Si no estás de acuerdo con estas citas, por favor no me mates, 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 CDK realmente satisface a los desarrolladores donde se encuentran. Ya hay muchos desarrolladores que están escribiendo aplicaciones en la nube con JavaScript y TypeScript y desplegándolas en AWS. Entonces, al utilizar una herramienta como esta, puedes escribir tu infraestructura y tus aplicaciones utilizando las mismas herramientas y lenguajes. Y eso siempre ha sido una de las ventajas de Node.js, ya que permitía a los desarrolladores front-end y back-end utilizar el mismo lenguaje común, y esto simplemente amplía aún más eso en

tu implementación y operaciones. El CDK también te ofrece una infraestructura probada, por lo que hay un módulo de aserción AWS CDK slash assert. Se integra muy bien con Jest y snapshot testing. Y luego, lo último que quería mencionar es que realmente no deberías preocuparte por el bloqueo del proveedor porque probablemente ya estás bloqueado a menos que tengas la aplicación más trivial. Poder pasar de AWS a algo como Azure probablemente requerirá algún esfuerzo en la portabilidad. Entonces, el CDK no te va a bloquear más de lo que ya estás bloqueado. Y luego, antes de profundizar demasiado, quería algo que descubrí mientras investigaba el CDK y que me pareció interesante, fue algo llamado JSII, que significa la Interfaz de Interoperabilidad de JavaScript. Y esto es en cierto modo la herramienta que se encuentra debajo del CDK que le permite escribir en TypeScript, pero aún es compatible con todos los demás lenguajes que mencioné anteriormente. Y cuando leí sobre esto originalmente, pensé que probablemente funcionaba generando código específico del lenguaje. Pero en realidad, en el fondo, se basa en un runtime de Node.js, y lo que hace es ejecutar tu código de TypeScript y enviarlo de ida y vuelta, la entrada y salida, entre el proceso secundario de Node y el proceso principal que ha estado ejecutando tu aplicación. Y hay algunas uniones generadas que forman parte de la salida del CDK, por lo que puedes escribir tu código una vez y obtendrás la misma API en todos estos diferentes lenguajes. Y eso desafortunadamente tiene un impacto en el rendimiento, porque estás iniciando un proceso de Node, estás interactuando con un proceso secundario, en lugar de generar el código directamente. Pero pensé que era algo interesante y quería compartirlo como parte de esta charla. Así que volviendo al punto principal de esta charla, mencioné CloudFormation anteriormente. CloudFormation es un conocido servicio de AWS que básicamente te permite definir tu arquitectura, tus recursos que utilizarás en la nube como un archivo de plantilla JSON o YAML. Y luego se puede implementar a través del servicio de CloudFormation. Se encargará de crear todos los recursos que necesites, como instancias o funciones Lambda o cualquier otra cosa de ese tipo. Y en realidad puede administrar grupos grandes de recursos como una unidad única que se llama pila. Por lo tanto, las pilas se pueden crear, actualizar y modificar, también se pueden eliminar y todo lo que sucede a ese grupo completo como una sola entidad. Por lo tanto, 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 luego, dentro de CloudFormation, básicamente hay entradas y salidas para tu pila de CloudFormation. Las entradas se llaman parámetros y son útiles para pasar cosas como información sensible o si estás 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 salida. 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 usar 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. Mantener estos archivos JSON y YAML a mano puede ser bastante trabajo y propenso a errores. 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 constructos. Los constructos son la forma en que construyes y compones aplicaciones de CDK y hay una variedad de diferentes tipos de constructos en diferentes niveles. Por ejemplo, el

El nivel 1 de constructo es básicamente un recurso de CloudFormation. CFN aquí significa CloudFormation de forma abreviada. Por ejemplo, hay un constructo de CDK llamado CloudFormation bucket y esto es simplemente un envoltorio básico alrededor de CloudFormation. Pero luego, los constructos de nivel 2 llevan eso a un nivel superior para introducir una API basada en intenciones. 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 de nivel superior 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 pasarela de API y cosas así, puedes simplemente usar el patrón de API REST de Lambda. Como dije, realmente puede acelerar la productividad. Y la forma en que funcionan estas aplicaciones es que tomas tus diferentes constructos y los compones en lo que se llama un árbol de constructos. Y también vale la pena señalar que AWS proporciona una gran cantidad de constructos desde su biblioteca, pero también es posible que los usuarios creen sus propios constructos para adaptarlos a sus necesidades. Entonces, hay dos tipos especiales de constructos que vale la pena discutir un poco. Son las aplicaciones y las pilas. Por lo tanto, la raíz del árbol de constructos siempre será un componente de aplicación. La razón por la que se llama aplicación es porque las aplicaciones de CDK se denominan aplicaciones. Como dije, esto siempre será la raíz, pero las pilas son constructos que se asignan a pilas de CloudFormation. Mencioné que en CloudFormation, los grupos de recursos se agrupan como una pila, y esto es una correspondencia uno a uno. Por lo tanto, las aplicaciones contienen pilas, por lo que puedes tener más de una en una sola aplicación, y luego las pilas son las que contienen los otros constructos. Una cosa que vale la pena señalar es que cada pila se configura mediante un entorno, y hablaré de eso ahora mismo. Un entorno es un ID de cuenta de AWS, más una región donde se implementará la pila. Básicamente, esto significa que este usuario se implementa en esta región en la nube, y 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 no depende del entorno. Pero esto tiene un uso bastante limitado. Y para proporcionar el entorno, si alguna vez has trabajado con alguna de las herramientas de AWS antes, hay varias formas de hacerlo. En el propio código, puedes pasar valores al constructor de la pila, pero también puedes pasar un indicador de perfil desde la línea de comandos o especificar diferentes variables de entorno, y automáticamente las recogerá en el código y sabrá dónde implementar tus cosas. Y 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 esto, creo que podemos generar nuestra primera aplicación de CDK. He agregado un comando de línea de comandos simple aquí utilizando 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 que queremos usar aquí, pero puedes pasar cualquiera de los otros lenguajes admitidos.

Y esto 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. Esto crea una carpeta bin, y así puedes ejecutar este archivo directamente. Puedes ver el pequeño shebang en la parte superior del código aquí que la mayoría de los binarios de node incluyen.

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 primer argumento, así es como el Árbol de Constructos realiza un seguimiento de qué constructos son hijos de qué otros constructos. Y luego vamos a llamar a esta pila de prueba, así que eso es lo que es la segunda opción allí. Así que al ver 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 ejemplos futuros, los eliminaré para ahorrar espacio. Lo primero que hacemos es importar el cdk en sí, y luego creamos una clase TestStack, que extiende la clase cdkStackBase. El constructor de una clase toma un alcance, un ID y props. El alcance es el constructo padre, como mencioné antes. El ID es el ID lógico del constructo cuando sintetizamos y desplegamos estas aplicaciones. Y luego los props son un mapa opcional que se puede pasar y que se utiliza para definir otras propiedades de tu constructo.

Entonces, si queremos agregar más constructos, podríamos hacer algo como esto, npm install dash dash save awscdk slash awsec2, esto básicamente instalará los constructos de CDK para el servicio EC2. En este ejemplo simple, estoy agregando una VPC a nuestra pila. La razón por la que hago esto es porque las VPC se pueden implementar sin costo adicional, así que si quieres experimentar con esto y implementarlo, 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 qué son algunos de los otros más adelante. Y lo que hace es que lee el código fuente de tu aplicación, pasa por lo que se llama la fase de construcción de constructos, donde se ejecuta el código del usuario y se ejecuta toda la cadena de constructores. Así que básicamente está construyendo el árbol de constructos. Las fases de preparación y validación son ganchos disponibles para los constructos, pero generalmente no son necesarios. Y a veces incluso se desaconsejan. Y luego viene la fase de síntesis, que genera algo llamado un conjunto de recursos en la nube. El conjunto de recursos en la nube será tu plantilla de formación en la nube, así como cualquier otro artefacto de implementación que se necesite para implementar tu aplicación en la nube. Hablaré sobre qué son esos otros artefactos de implementación en un momento. Y luego la implementación tomará tu conjunto de recursos en la nube y, ya sabes, cargará todo lo que necesite ser cargado en la nube y comenzará una implementación de CloudFormation. Y una vez que eso tenga éxito, tendrás una aplicación de CDK que está implementada en la nube. Puedes hacer la etapa de síntesis como un paso separado sin necesidad de implementarla, lo cual es útil para pruebas locales y pruebas unitarias. Para hacer eso, puedes usar el comando MPX AWS CDK, synth, y luego el nombre de tu pila. En este caso, test stack, esto generará tu pequeña aplicación de CDK en una plantilla de formación en la nube. Generará cualquier artefacto de implementación, como imágenes de Docker, si estás implementando alguna función lambda, las empaquetará para ti. Y luego escribirá todo tanto en la salida estándar, ya que esto es solo una síntesis y no una implementación, pero también creará tu directorio CDK dot out, que es donde se almacena todo antes de implementarlo. Y luego puedes ver a la derecha aquí, he capturado cómo se ve la plantilla de formación en la nube. Y puedes ver que, ya sabes, ocupa toda la altura de la diapositiva y es muy ilegible. Y eso se basa en una aplicación de CDK, que tenía aproximadamente una docena de líneas de JavaScript. Así que puedes ver de dónde viene, ya sabes, el aumento de la verbosidad con CloudFormation, así como, ya sabes, el poder expresivo de CDK.

A continuación, quiero hablar sobre activos y la inicialización. Así que cualquier archivo o directorio local que necesite ser cargado en S3, o cualquier imagen de Docker local que necesite ser cargada en el registro de contenedores elástico, 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 herramientas de CDK. Y consta de un bucket de S3 y un conjunto de recursos de 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 algo más realista

Por ejemplo. Ahora vamos a desplegar un sitio estático en S3. He incluido un asterisco aquí porque, una vez más, se te cobrará por AWS si ejecutas esto. Así que 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. Voy a llamar a mi bucket bucket del sitio web, voy a hacer que el índice sea index.html, la página de inicio de mi sitio que estoy desplegando. Y voy a otorgar acceso de lectura público al mundo para que cualquier persona pueda venir y ver mi sitio. Y luego, para desplegarlo, usaré el constructo de implementación del bucket de despliegue de S3. Así que lo estoy adjuntando a la pila, lo llamo despliegue, mi sitio web, las fuentes vendrán de un directorio local que llamo www, eso creará activos, como mencioné en la diapositiva anterior. Esa es la parte por la que se te cobrará. Y luego subirá todo al bucket que acabamos de crear llamado bucket del sitio web. Una cosa que vale la pena señalar aquí, este es un ejemplo pequeño, porque tiene que caber en una diapositiva. Pero podrías llevar esto más lejos y agregar cosas como DNS o CDN para crear un sitio estático agradable para ti. Entonces, para desplegar realmente el sitio, diríamos mpx AWS CDK deploy pila del sitio web, y luego pasaré mi perfil de AWS desde la línea de comandos para que sepa a qué entorno desplegar. Pero la primera vez que ejecuto esto, veré el siguiente error. Dice esta pila utiliza activos, por lo que la pila de herramientas debe desplegarse en el entorno. Entonces, eso significa que tengo que inicializar este entorno primero, y puedes ver a continuación que he agregado mpx, AWS CDK, bootstrap, y luego paso mi perfil que creará la infraestructura de inicialización de la que hablé antes, luego puedo volver a ejecutar el mismo despliegue y todo debería funcionar según lo planeado esta vez.

Entonces, si quieres ver cómo se ven esos recursos desplegados, 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 realmente desplegado y funcionando en producción. Como dije, si quieres hacer esto un poco más sofisticado, podrías agregar cosas como DNS y los CDNs. Podrías 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 vayas a la consola web de AWS y veas S3 y CloudFormation para asegurarte de que todos los recursos se hayan eliminado. He vinculado a continuación un problema de CDK donde la inicialización no siempre se limpia a sí misma. Así que quería proporcionarte aquí comandos que puedes usar para limpiar o simplemente hacer 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 todos básicamente los comandos que usamos para hacer el despliegue. Puedes instalar AWS CDK localmente. Si haces eso, entonces se convierte en

conocido como CDK y no como AWS CDK. Así que eso es algo a tener en cuenta. También puedes instalarlo de forma global con la bandera -G, pero no lo recomiendo realmente. Las dependencias globales generalmente no son lo mejor. Por eso recomiendo agregarlo a tu package JSON y luego llamarlo desde uno de tus scripts de NPM. También hay otros comandos útiles aquí de los que no hablé. CDK LS mostrará las pilas que están en la aplicación. Dif comparará la pila con la versión desplegada 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 utilizando CDK context. Hay un comando doctor, que puede analizar tu proyecto y buscar posibles problemas. Y luego CDK doc se puede usar para abrir la documentación oficial en tu navegador. Es una especie de acceso directo.

Y finalmente, quería incluir aquí algunos recursos adicionales. El primer enlace es la documentación oficial. El segundo enlace es el código fuente de CDK. Y luego, 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 rápidamente y ponerlo en marcha. Eso es todo lo que tenía. Gracias nuevamente por asistir a mi charla y que tengas un buen día a todos. Me alegra ver que muchas personas no han utilizado el CDK antes. Espero que la charla sea una especie de inspiración para que lo prueben. ¿Te sorprendieron esas respuestas? No realmente. Es una herramienta bastante nueva. Y también se utiliza para despliegues y en muchos lugares de desarrollo de software, los desarrolladores no se encargan realmente del despliegue. Así que no me sorprendió realmente. Entiendo, tiene sentido. Echemos un vistazo en

Canal de preguntas y respuestas de Node Talk. Algunas preguntas para ti. David, Liam pregunta, ¿hay algún servicio de AWS que no esté cubierto en el CDK? Sí, el CDK aún no cubre todas las diferentes cosas que AWS puede hacer. Sé que están agregando activamente cosas nuevas. Pero también AWS siempre está agregando nuevas cosas también. Así que es muy difícil mantenerse al día con algo que ya es tan masivo. Sí, tiene sentido. Max preguntó, ¿no es Terraform más eficiente porque no utiliza una plantilla de CloudFormation? En realidad, no sé cómo funciona Terraform internamente. Pero Terraform, quiero decir, Terraform es una gran herramienta. Ha estado presente durante mucho más tiempo y ha sido probado en batalla y funciona en otras nubes también. Pero, como dije en la charla, una de las ventajas del CDK es, en primer lugar, el soporte de primera clase de AWS. Pero además, permite a los desarrolladores de JavaScript escribir sus implementaciones utilizando JavaScript en lugar de tener que aprender Terraform y ES5 versus ESL que utiliza Terraform. Así que creo que, ya sabes, no es un reemplazo para todo, pero es solo otra herramienta para tu caja de herramientas. Claro, claro. Soy un desarrollador de JavaScript. Y me encanta que muchas cosas se estén moviendo a JavaScript. JavaScript está en todas partes. Tenemos un comentario de Juan Gonzales. Dijo que la charla realmente despertó su interés por el CDK. Uno más para agregar a mi lista de aprendizaje. Así que es comprensible que la gente no haya probado aún. ¿Cuándo fue la primera vez que lo probaste? ¿Cómo fue cómo? ¿Cómo te metiste en esto? En realidad, fue bastante reciente. Escuché hablar de ello y leí sobre ello en Twitter. Así que empecé a investigarlo y me pareció interesante. Y quería tener una razón para aprenderlo mejor y experimentar con él. Y luego me pidieron que hablara en esta conferencia. Así que hice todo el desarrollo impulsado por la charla de la conferencia, o como lo llamen. Básicamente, lo aprendí para esta charla. Y tuve una muy buena experiencia usándolo. Así que espero que otros también la tengan. Sí, eso es genial. Bueno, gracias por aprenderlo para la

charla. También he hecho esto como desarrollo impulsado por conferencias. Siempre es realmente interesante verlo. Creo que es una forma muy agradable de enseñar a las personas porque estás aprendiendo mientras avanzas. Y las preguntas que tenías probablemente son las preguntas que las personas que están aprendiendo también tienen, ¿encontraste algún desafío mientras empezabas con esto? Sé que pensé que estaba realmente bien documentado y era fácil de usar. No intenté usar ninguna de las características que tiene AWS que el CDK aún no admite. Así que no me encontré con ninguno de esos problemas. Pero descubrí esa tecnología JSII que mencioné allí y me adentré en ese tema y me sorprendió ver cómo funcionaba internamente. Así que sí, fue un buen momento. Tú también miraste bajo el capó. Eso es muy

interesante. Hagamos otra pregunta. Tenemos, um, alguien preguntó, actualmente estoy usando terraform. ¿Por qué debería migrar a CDK? Bueno, sabes, si ya tienes un flujo de trabajo existente y una configuración existente, no recomendaría arrancarlo y reescribirlo solo por el hecho de reescribirlo. Pero si estás, si estás empezando algo nuevo en AWS, si aún no conoces terraform, creo que la curva de aprendizaje sería mucho menor usando algo como el CDK. Así que ahí es donde lo recomendaría. Sé que hay muchos fanáticos acérrimos de terraform que no van a hacer el cambio y está bien porque realmente no es necesario. Sí, cambiar las cosas, especialmente la infraestructura, es súper complicado. ¿Alguna vez has tenido que hacer una migración así? No de una, no de una herramienta de infraestructura a otra Ahora. Qué suerte tienes. Yo tampoco he tenido que hacerlo, pero solo he escuchado las historias de terror y, oh, me estremezco solo de pensarlo

. Um, alguien más preguntó, el CDK es un proyecto de código abierto. ¿Puedo contribuir o al menos proporcionar aportes? Sí, si quieres contribuir, es de código abierto. Personalmente no he contribuido, así que no puedo comentar sobre cómo es esa experiencia si es agradable o no. Pero incluso si no quieres contribuir con código, hay una hoja de ruta y otras cosas en las que las personas pueden solicitar funciones. Hay un tablero de proyectos en GitHub donde puedes ver en qué está trabajando el equipo y qué están planeando para el futuro. Así que creo que una cosa que llamó la atención fue el soporte para algo que planeaban agregar. Así que sí, definitivamente puedes dar comentarios y ver cómo se está desarrollando de manera abierta. Así que puedes ver qué está sucediendo.

Genial. Me encanta eso. Incluso si solo es ver qué hay por delante, nos ayuda a tomar decisiones sobre si queremos implementarlo o si están surgiendo cosas. Y creo que es increíble. Si tienes ese aporte, sé que las empresas que construyen software para otros desarrolladores suelen estar interesadas en saber cómo los desarrolladores adoptarán ese tipo de cosas. Sí, al final del día, quiero decir, lo están construyendo probablemente para sus propios propósitos internos, pero también para todos los clientes de AWS. Entonces, ¿por qué no intentar ver qué es lo que la gente realmente quiere y necesita? Sí, tiene sentido. Um, Alexi en el chat está preguntando, ¿qué nivel de experiencia de AWS se requiere para comenzar a usar el producto CDK de AWS de manera productiva? Yo diría que solo tienes que saber qué quieres construir en AWS. Entonces, ya sabes, si conoces JavaScript y sabes qué quieres construir en AWS, creo que es extremadamente fácil comenzar. Si nunca has usado AWS antes y ni siquiera sabes qué es una función lambda o qué es un contenedor, algo así, probablemente necesitarás saber qué estás tratando de construir primero. Pero aparte de eso, la puesta en marcha, al menos, en mi opinión, fue muy sencilla. Genial. Y hey, Colin, hemos estado preguntando, hemos estado preguntando a nuestros oradores hoy si pueden compartir un poco sobre, ya que estamos preguntando sobre la experiencia, nos encantaría saber, ¿cómo te metiste en la programación? ¿Cuál es tu historia? Era un nerd de la informática cuando era niño. Así que recuerdo haber tenido AOL y cosas así. Y luego quería aprender a hacer páginas web. Y las páginas web tienen JavaScript. Y simplemente me gustaba mucho lo que podía hacer con JavaScript allí. Aprendí, ya sabes, supongo que programación más formal en la universidad, y aún así terminé volviendo a JavaScript de todos modos, porque es es un lenguaje tan divertido. Es realmente un lenguaje divertido, ¿verdad? ¿Tienes alguna destacada de cosas que has construido con JavaScript que te emocionen? Cosas, así que supongo que una de mis contribuciones más grandes en JavaScript fue cuando estaba trabajando en gRPC. No tenían una implementación de TypeScript del lado del servidor para eso. Así que tuve que construir eso. Y creo que es

actualmente se envía con el módulo oficial de gRPC. Y obtuve un par de charlas en conferencias gracias a eso. Así que creo que eso es increíble. Eso es realmente genial. También estuvimos hablando detrás del escenario de que viniste y diste una charla en JSConf Colombia en 2019. Y recuerdo que una de las cosas que destacaron fueron tus contribuciones al comité directivo técnico. ¿Quieres hablar un poco sobre tu papel en el TSC de Node? Sí, he estado contribuyendo a Node desde hace un tiempo, creo que desde 2014. Y el TSC es el órgano de toma de decisiones final, aunque no nos gusta serlo, preferimos que los demás colaboradores y el consenso general impulsen las cosas. Pero a veces, cuando hay un problema, es necesario votar o algo así. Pero también quiero tomarme un momento para decir que si tienes la oportunidad de ir a Colombia a una de sus conferencias, lo recomiendo mucho. Eso es muy amable. Sí, estábamos hablando de cómo intentamos brindar a nuestros ponentes una experiencia realmente excelente. Así que definitivamente échale un vistazo si hacemos conferencias, una vez que todo esto haya terminado. ¿Qué fue lo que más te gustó? ¿Qué fue lo que más te gustó de tu experiencia en Colombia, Colin? Pensé que la configuración del escenario era muy agradable. Me gustó que, ya sabes, la forma en que los ponentes eran atendidos, en cuanto al transporte desde el aeropuerto y todo eso, fue una experiencia muy fluida para mi primera vez en Sudamérica. Así que gracias por eso. Me encanta. Muchas gracias por unirte a nosotros. Colin, todos, por favor, den un gran aplauso a Colin por unirse a nosotros para esa sesión de preguntas y respuestas y esa increíble charla. Gracias, Colin.