AWS Lambda bajo la superficie

Spanish audio is available in the player settings
Rate this content
Bookmark
Slides

En esta charla explico cómo funciona el servicio AWS Lambda, explicando la arquitectura, cómo escala y cómo un desarrollador debe pensar cuando diseña su software utilizando funciones Lambda

22 min
17 Apr, 2023

Video Summary and Transcription

En esta charla se cubren las características clave de las funciones de AWS Lambda, incluyendo la arquitectura del servicio, la composición y la optimización del código Node.js. Se explican los dos modelos operativos de Lambda, la invocación asíncrona y síncrona, destacando la escalabilidad y disponibilidad del servicio. Se discuten las características de las funciones de Lambda, como los reintentos y el mapeo de la fuente de eventos, junto con el ciclo de vida de la micro VM y las tres etapas de una función Lambda. Se explican técnicas de optimización de código, incluyendo la reducción del tamaño del paquete y el uso de opciones de almacenamiento en caché, y se recomiendan herramientas como webpack y Lambda Power Tuning para la optimización. En general, Lambda es un servicio potente para manejar la escalabilidad y los picos de tráfico mientras permite a los desarrolladores centrarse en la lógica empresarial.

Available in English

1. Introducción a AWS Lambda

Short description:

En esta sesión, cubriremos las características clave de las funciones Lambda, cómo funciona la arquitectura del servicio, cómo componer una función Lambda en AWS y cómo optimizar tu código Node.js para Lambda. Una función Lambda te permite centrarte en crear valor para tus clientes escribiendo código que mapee tus capacidades empresariales en producción. Solo pagas por el tiempo de ejecución, lo que lo hace rentable tanto para entornos de producción como de prueba. Puedes proporcionar tu código a través de un archivo zip o imágenes de contenedor, y elegir entre una variedad de lenguajes integrados o traer el tuyo propio. Incluso un cliente creó un tiempo de ejecución personalizado en COBOL.

Hola a todos y bienvenidos a esta sesión sobre AWS Lambda bajo la lupa. Sé que varios de ustedes no solo están interesados en cómo construir código, sino también en por qué deberían construirlo de cierta manera. Ya sea que sean expertos en escribir funciones Lambda o estén pensando en usar serverless y AWS Lambda en su próxima carga de trabajo, creo que al final de esta charla podrán tomar una decisión consciente sobre por qué escribir el código de cierta manera.

Así que sin más preámbulos, vamos a continuar. Mi nombre es Luca. Soy un especialista principal en serverless en AWS. Estoy basado en Londres. Soy un orador internacional y autor de libros. En esta charla vamos a cubrir bastante terreno, y especialmente lo que quiero abordar es, en primer lugar, ¿qué es una función Lambda? Porque tal vez tengan una idea de lo que es, pero intentemos definir las características clave de las funciones Lambda. Luego pasamos a comprender cómo funciona la arquitectura del servicio bajo la lupa. Luego discutimos cómo componer una función Lambda en AWS. Y luego nos adentramos en los ciclos de vida de las funciones y cómo aprovecharlos al máximo para beneficiar a tu código. Y por último, pero no menos importante, hablaremos sobre cómo optimizar tu código Node.js para Lambda.

Hay mucho terreno que cubrir, así que empecemos. ¿Qué es una función Lambda? En pocas palabras, una función Lambda es tan simple como proporcionar un poco de código y nosotros nos encargamos de aprovisionar y administrar el servicio por ti. Por lo tanto, no tienes que preocuparte por el aspecto de la red o cómo orquestar la escalabilidad, etc. Solo te enfocas en lo que realmente importa para ti. Crear valor para tus clientes y además escribir un poco de código Node.js que básicamente mapea tus capacidades empresariales en producción. Pagas por milisegundo. Por lo tanto, cada vez que invocas una Lambda, pagas solo por el tiempo de ejecución y nada más. Y esa es una excelente manera de pensar no solo en producción, sino también en entornos de prueba o entornos de puesta en escena que no se utilizan las 24 horas del día, los 7 días de la semana, como tu entorno de producción. Allí, solo pagas por lo que usas. No tienes que aprovisionar contenedores o máquinas virtuales que estén allí las 24 horas del día. Puedes servir el contenido de dos maneras. Puedes proporcionarnos tu código a través de un archivo zip cuando el archivo tiene hasta 250 megabytes, o si es más grande que eso, puedes usar imágenes de contenedor de hasta 10 gigabytes. En ambos casos, puedes aprovechar los beneficios de AWS Lambda sin ningún problema. También ofrecemos lenguajes integrados. Tenemos algunos tiempos de ejecución que están disponibles y son administrados por nosotros para ti, como Java, Go, Node.js, .NET, Python y muchos otros. Pero también, si tienes un caso de uso específico, puedes traer el tuyo propio, y lo operacionalizamos de la misma manera exacta. Un ejemplo clásico, tuvimos un cliente que trabajaba en finanzas y necesitaba usar COBOL, pero realmente se enamoraron de Lambda, así que crearon su propio tiempo de ejecución personalizado en COBOL.

2. Modos de Invocación y Arquitectura de Lambda

Short description:

Por último, pero no menos importante, escala en milisegundos. Lambda tiene dos modelos operativos: invocación asíncrona e invocación síncrona. El código que escribes se ejecuta dentro de un sandbox de MicroVM, que es parte de un Worker que opera en una zona de disponibilidad. AWS se encarga de hacer que tu código esté altamente disponible en múltiples centros de datos. En el modo síncrono, el API Gateway llama a un servicio frontal en AWS Lambda, que invoca inmediatamente a un worker para ejecutar tu código y devolver la respuesta. En el caso de las funciones Lambda síncronas, los eventos se envían a una cola de mensajes y el llamador recibe una confirmación.

Por último, pero no menos importante, escala en milisegundos. Así que, según el patrón de tráfico, nos encargamos de escalar tu función Lambda y responder a todas las solicitudes que llegan. Por lo general, desde la perspectiva del desarrollador, lo que ves es que estás escribiendo código, como puedes ver a la izquierda de esta diapositiva, y luego lo cargas en tu cuenta de AWS, y ocurre algo mágico, y comienzas a tener una API que funciona.

La realidad es que hay mucho más. Entonces, la pregunta ahora es, ¿alguna vez has pensado cómo funciona Lambda bajo el capó? Echemos un vistazo a eso. En primer lugar, hay dos modelos operativos de las funciones Lambda. El primero es la invocación asíncrona, donde, por ejemplo, tienes un API Gateway que expone tu API, llega una solicitud de un cliente, y una función Lambda es desencadenada con la respuesta, y luego sirves la respuesta de forma síncrona a tu cliente. La otra opción es la invocación asíncrona, donde en este caso tienes un servicio que empuja un evento al servicio Lambda, el servicio Lambda almacena el evento en una cola interna de eventos, y luego la función Lambda comienza a recuperar estos eventos de manera lenta pero constante y realiza algún trabajo en ellos. El solicitante, en este caso Amazon EventBridge, por ejemplo, recibe directamente una confirmación y nada más. Esas son las dos formas en que funciona la invocación de Lambda.

Entonces, si vemos el panorama general, cómo desde lo que ves a la izquierda de la diapositiva, ya sea que haya múltiples servicios o incluso síncronos o no, están enviando una solicitud al servicio AWS Lambda, que es el gran rectángulo que está dentro de esta diapositiva. Y cómo pasar a tu código que está a la extrema derecha de esta diapositiva, donde hay un sandbox de MicroVM, es un viaje interesante. Y especialmente, quiero resaltar primero lo que sucede dentro de tu sandbox. El sandbox es donde se ejecuta tu código. Ahora, si piensas en eso, tu MicroVM, donde está el código que has escrito y que nosotros operacionalizamos, se ejecuta dentro de un Worker. Y obviamente, no hay solo un Worker. Hay muchos más. Por lo general, en AWS, tenemos múltiples zonas de disponibilidad. Y como puedes ver aquí, tienes múltiples Workers ejecutándose dentro de una zona de disponibilidad. Y la zona de disponibilidad es un centro de datos. Así que piensa en cómo se ve un centro de datos, y esa es tu zona de disponibilidad. Pero por lo general, en AWS, cada vez que creamos una región, está compuesta por múltiples zonas de disponibilidad. Por lo tanto, cada vez que estás enviando el código a Lambda, automáticamente tendrás tu código disponible en múltiples centros de datos. No tienes que hacer nada. Solo te enfocas en qué región deseas implementar y cuál es la lógica empresarial. Y nosotros nos encargamos no solo de operacionalizar el código, sino también de hacerlo altamente disponible en toda nuestra infraestructura. Ahora echemos un vistazo más profundo al modo de invocación y cómo funciona dentro de la arquitectura.

En el modo síncrono, lo que sucede es que, por ejemplo, en el API Gateway se llama de forma síncrona a un servicio frontal que está dentro del servicio AWS Lambda y que devuelve una respuesta inmediata porque lo que sucede es que se invoca a un worker específico, se inicia una MicroVM y tu código comienza a ejecutarse y devuelve inmediatamente tanto la respuesta como el error al cliente. En cambio, cuando estás pensando en el modo de invocación para funciones Lambda síncronas, es ligeramente diferente. En este caso, por ejemplo, tenemos SNS que está enviando un evento a un mensaje dentro del servicio frontal, el servicio frontal almacena en una cola interna el mensaje específico, el llamador recibe una confirmación que simplemente dice sí, hemos tenido en cuenta tu solicitud y luego ingresas a la cola interna.

3. Características de las Funciones Lambda y Ciclo de Vida de la Micro VM

Short description:

La belleza de Lambda es que admite características como reintentos, definición de destino y asignación de fuente de eventos. Con la asignación de fuente de eventos, puedes manejar fácilmente el procesamiento por lotes y el manejo de errores sin escribir lógica adicional. Cuando cargas código, se crea tu micro VM utilizando File Cracker, una micro VM de código abierto diseñada para funciones Lambda. Funciona cargando el código, creando la micro VM y eliminando los arranques en frío. Una vez creada la micro VM, tu función Lambda se ejecuta sin problemas y sin latencia. El ciclo de vida de una función Lambda involucra tres etapas.

Y la belleza de este enfoque es que no solo ejecutamos tu código, sino que también admitimos una serie de características, como la configuración del mecanismo de reintentos. Hasta tres invocaciones en total. Cuando algo falla, puedes definir el destino, e incluso puedes definir esa cola posterior que es un patrón útil cuando deseas reintentar automáticamente la creación de tu propio flujo de trabajo, los errores o incluso la depuración de tu sistema.

Hay un tercer método del que no hemos hablado, que es la asignación de fuente de eventos, y hay ciertos servicios como MSK o Kinesis o SQS o Dynamo Streams que utilizan otro servicio disponible en los servicios de Lambda de AWS llamado asignación de fuente de eventos. La asignación de fuente de eventos se encarga de extraer mensajes de la fuente y luego invocar de forma síncrona tu función Lambda. Gracias a la asignación de fuente de eventos, puedes realizar procesamiento por lotes, manejo de errores y mucho más. Lo bueno de esto es que, a diferencia de otros servicios, no necesitas escribir tu propia lógica. En este caso, para Lambda, todo está completamente abstracto para ti, por lo que solo configuras cómo se ve tu lote de mensajes y luego se envía a tu código de función Lambda para operacionalizar tu lógica empresarial.

Ahora, hemos visto cómo funciona el servicio, pero ahora intentemos entender cómo se ve cuando cargas algún código y tu micro VM se está ejecutando. Cada micro VM utiliza File Cracker. File Cracker es una micro VM de código abierto que creamos para las funciones Lambda, especialmente para la computación sin servidor, y ahora también está disponible para otros servicios de AWS. Es completamente de código abierto, como mencioné antes. Por lo tanto, puedes ver cómo funciona, pero es una pieza de software fantástica que utilizamos para operacionalizar tu código para las funciones Lambda.

Entonces, ¿cómo funciona? Por lo general, funciona de la siguiente manera. Cuando hay una entrada y alguien está desencadenando e invocando una función Lambda, seleccionamos un host de trabajador, la entrada del evento llega al host de trabajador. Lo primero que hace es cargar el código que has cargado. Esto generalmente se llama arranque en frío y significa que es en frío principalmente porque lleva un poco más de tiempo recuperar el código en tiempo de ejecución. Luego se crea tu micro VM con File Cracker y, obviamente, el tiempo de ejecución que has seleccionado o el contenedor. Hay diferentes niveles en cómo se almacenan en caché estas cosas dentro del sistema. Pero en general, la idea es que tienes un arranque en frío cuando construyes por primera vez la micro VM con el código y todo. Después de eso, tienes tu función Lambda en funcionamiento. Comienzas a llamar a la función Lambda de la micro VM varias veces con diferentes entradas y de repente ya no tienes arranque en frío. Tienes muchas respuestas que no se están gestionando. No tiene ninguna latencia en la generación de mi micro VM. Y eso es genial. Ahora creo que es un buen momento para pensar en la parte del ciclo de vida o cómo funciona la función Lambda cuando generas una nueva micro VM. Este es probablemente el mejor diagrama que puedo mostrarte, y está totalmente disponible en nuestro sitio web. Por lo general, cuando tienes una función Lambda, pasas por tres etapas.

4. Inicialización, Invocación y Apagado de Lambda

Short description:

Tienes las fases de inicialización, invocación y apagado en las funciones Lambda. Durante la inicialización, se cargan las extensiones y los tiempos de ejecución, y se realizan tareas específicas de la función, como recuperar secretos y establecer conexiones con bases de datos. En la fase de invocación, el entorno de ejecución está activo, lo que permite una respuesta rápida a las solicitudes. Finalmente, durante el apagado, se cierran los tiempos de ejecución y las extensiones. Para obtener más información, consulta la documentación.

Tienes las fases de inicialización, luego la invocación que ocurre varias veces hasta que tu entorno de ejecución siga activo y disponible, y luego el apagado, que es cuando, digamos, tu función Lambda ya no se llama. Por lo tanto, como dijimos, pagas por el tiempo de ejecución. Después de un tiempo, reclamamos la infraestructura y sigues adelante hasta la próxima invocación, obviamente. Ahora, en cada uno de esos pasos, tienes diferentes cosas que suceden. Así que empecemos a ver la fase de inicialización. En la fase de inicialización, tenemos, en este caso, la extensión porque puedes usar una extensión para tu función Lambda. Piensa en los sidecars que están disponibles en tus entornos de ejecución, y eso suele ser lo primero que se carga. Luego, está la carga del tiempo de ejecución. Por ejemplo, si seleccionaste node.js, se inicializa el tiempo de ejecución de Node, y luego, de repente, tienes la inicialización de la función. Aquí está una de las partes clave del sistema. Por lo general, en la inicialización de la función, lo que haces es, por ejemplo, recuperar secretos que se utilizan durante la invocación de tu función lambda, o incluso parámetros que se almacenan externamente a tu función lambda. Lo bueno de esto es que solo se hace en la fase de inicialización, por lo que no necesitas recuperar la información cada vez. Incluso establecer una conexión con una base de datos, puedes hacerlo en la fase de inicialización y luego olvidarte de eso. Estará disponible para todas las invocaciones que el entorno de ejecución realice. Luego, podemos pasar a la fase de invocación, donde el entorno de ejecución ya está activo y, por lo tanto, comienzas a responder a cada solicitud. Ten en cuenta que hasta que el entorno de ejecución esté activo, puedes omitir completamente la fase de inicialización. Por lo tanto, tu función lambda será bastante rápida, porque solo se invoca y está allí, disponible para ti. Al final, cuando reclamamos la función lambda, tienes un apagado del tiempo de ejecución y un apagado de las extensiones. Muy fácil. Si quieres saber más, puedes consultar la documentación en este enlace y podrás ver

5. Optimización de Código en Funciones Lambda

Short description:

Para optimizar tu código en Lambda, reducir el tamaño del paquete es crucial. Herramientas como webpack y ESBL pueden ayudar a eliminar dependencias y funciones innecesarias, lo que resulta en tiempos de inicio de código más rápidos. La concurrencia provisionada es útil para cargas de trabajo predecibles, lo que te permite mantener las funciones Lambda activas durante los períodos de mayor tráfico. La nueva versión 3 del SDK de JavaScript AES ofrece un tamaño de paquete más pequeño y manejo incorporado de conexiones TCP. Las opciones de almacenamiento en caché de Lambda incluyen el almacenamiento en caché en memoria en el entorno de ejecución y el uso de servicios como Elastic File System o Elastic Cache para el almacenamiento de datos en varias funciones. La herramienta de código abierto Lambda Power Tuning ayuda a optimizar el tiempo de invocación y el costo al determinar la mejor configuración, incluida la arquitectura y el tamaño de memoria. Lambda Power Tools simplifica la observabilidad con registros, rastreo e integración de métricas. Lambda es un servicio potente que te permite centrarte en la lógica empresarial mientras manejas la escalabilidad y los picos de tráfico. Para obtener más información, consulta otras charlas y el documento técnico de seguridad.

más información sobre este diagrama y cómo funciona el ciclo de vida. Ahora, hablemos de cómo puedes optimizar tu código en la función lambda, especialmente en el código de Node.js. Como dijimos aquí, tenemos nuestra entrada que se recibe externamente del servicio, luego generas un microvm con tu código. Pero obviamente, para reducir el tiempo de inicio del código, una de las técnicas clave es tratar de reducir el tamaño del paquete. ¿Y cómo funciona esto? Puedes usar webpack, ESBL, cualquier herramienta que sea necesaria para reducir el tamaño del paquete. Esto obviamente hará que el inicio del código sea más rápido porque de repente tu código es solo una pieza de lógica y un montón de bibliotecas que estás usando. Pero todas las dependencias de desarrollo, por ejemplo, y todas las funciones que no están utilizando ese código que puedes eliminar, el tree shaking que puedes aplicar, son totalmente útiles para reducir el inicio del código cuando trabajas con funciones Lambda. Otra funcionalidad que está disponible en Lambda, si tienes una carga de trabajo específica, por ejemplo, imagina que tienes una carga de trabajo predecible y sabes de antemano que los domingos por la noche de 7pm a 9pm, vas a tener un aumento de tráfico, puedes usar concurrencia provisionada. La concurrencia provisionada básicamente te permite establecer un marco de tiempo y seleccionar una función Lambda específica para mantenerla activa. Entonces, lo que sucede es que seleccionamos tu función Lambda y comenzamos a inicializarla de antemano para ese período de tiempo específico en el que vas a tener algunas funciones Lambda disponibles y que ya están activas para satisfacer el aumento de tráfico. Esa es una forma fantástica de escalar tus cargas de trabajo sin tener un inicio en frío y además, si tienes un nivel superior de espera, la fase de inicialización se encargará de esa parte y, por lo tanto, lo que sucederá es que cosas como, por ejemplo, recuperar parámetros de fuentes externas como el sistema o el almacén de parámetros del administrador del sistema estarán disponibles en la fase de inicialización y luego no los necesitarás más, por lo que reducirás el tiempo de ejecución de tu función Lambda. Otra sugerencia es usar la versión 3 del SDK de JavaScript AES. Eso es un lanzamiento bastante nuevo y, obviamente, el paquete es más pequeño en comparación con la v2 y eso es algo genial. También hay muchas otras características que son bastante útiles, por lo que antes estabas usando la versión 2 del SDK y DynamoDB, una sugerencia que solemos dar es que debes mantener viva la conexión TCP, de lo contrario, cada vez que llames y ejecutes la función Lambda, se establecerá una nueva conexión TCP. Ahora, estas cosas están desapareciendo con la versión 3 y están incorporadas en el SDK, por lo que ya no tienes que manejarlas tú mismo, además, algo que a menudo la gente no sabe es que los tiempos de ejecución de Node.js incluyen una versión específica del SDK de AWS, por lo tanto, si no estás usando una versión específica del SDK o ya estás utilizando una implementación optimizada o algo similar, no necesitas incluir el SDK en tus dependencias, sino que puedes aprovechar el que se envía junto con el tiempo de ejecución, por lo que tienes una dependencia menos que manejar.

El almacenamiento en caché para Lambda se puede realizar en memoria y hay dos formas de hacerlo. La caché en memoria puede ocurrir en el entorno de ejecución, como hemos visto antes en tu micro VM, y eso ocurre en la fase de inicialización, como hemos visto en la charla anteriormente. También tienes una carpeta temporal que puede almacenar hasta 10 gigabytes de datos, de forma predeterminada son 512 megabytes, pero obviamente puedes aumentar este límite. También puedes almacenar y cachear en varias funciones Lambda si es necesario. Por ejemplo, puedes usar servicios como Elastic File System o Elastic Cache utilizando Redis o Memcache en el caso de Elastic Cache para almacenar tus datos en varias funciones Lambda. En ese caso, se recuperarán de EFS o Elastic Cache y estarás listo para continuar. Otra herramienta que vale la pena mencionar y una optimización con una alta relación de enlaces es usar una herramienta de código abierto llamada Lambda Power Tuning. Power Tuning ejecuta tu código y tu función Lambda de manera que te permite entender cuál es la mejor configuración para el tiempo de invocación de tu función Lambda y el costo de la invocación. Obviamente, hay diferentes parámetros que puedes configurar y muy a menudo la gente piensa que la menor cantidad de memoria siempre será la más barata, pero en realidad no lo es, y por eso tenemos esta herramienta que puedes ejecutar y comprender cuál es la arquitectura correcta para ejecutar Lambda, podría ser ARM o x86, y también cuál es el tamaño de memoria correcto basado en la optimización que deseas. Como puedes ver en esta diapositiva, puedes optimizar para el costo, puedes optimizar para el tiempo y ambas son dimensiones válidas para tener en cuenta. Por último, pero no menos importante, hay una biblioteca llamada Lambda Power Tools que simplifica la integración de la observabilidad en tu Lambda. De hecho, el registro, el rastreo y las métricas se vuelven muy sencillos gracias al uso de Lambda Power Tools y te permitirá tener las mejores prácticas incorporadas en tu código de forma automática. Si quieres saber más, puedes encontrar el enlace en esta diapositiva. Para resumir lo que hemos visto hasta ahora, Lambda es un servicio fantástico que te permite usar solo lo que realmente necesitas. Optimizas tu enfoque, tu día a día en la creación de lógica empresarial más que en operar tu infraestructura y definitivamente poner fin a esos picos de tráfico hasta cierto punto y también a otros tipos de cargas de trabajo. Si quieres saber más sobre cómo funciona Lambda internamente, hay otra charla que realmente recomiendo que fue realizada por un colega mío, Julian Wood, y también con un Ingeniero Principal del Equipo de Lambda que hablará más en profundidad sobre lo que hemos visto hasta ahora y también puedes echar un vistazo al documento técnico de seguridad que está disponible en el sitio web de AWS y que proporciona una gran cantidad de información sobre el modelo de seguridad y cómo funciona Lambda internamente. ¡Espero que hayas disfrutado de esta sesión y disfruta del resto de la conferencia!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2023React Summit 2023
28 min
Advanced GraphQL Architectures: Serverless Event Sourcing and CQRS
GraphQL is a powerful and useful tool, especially popular among frontend developers. It can significantly speed up app development and improve application speed, API discoverability, and documentation. GraphQL is not an excellent fit for simple APIs only - it can power more advanced architectures. The separation between queries and mutations makes GraphQL perfect for event sourcing and Command Query Responsibility Segregation (CQRS). By making your advanced GraphQL app serverless, you get a fully managed, cheap, and extremely powerful architecture.
DevOps.js Conf 2024DevOps.js Conf 2024
30 min
Demystify the DX for Lambda functions
In this session, I share with you how AWS CDK and AWS Toolkit can simplify the developer experience to run serverless workloads in the cloudA session with no slides, just an IDE and a CLI for deploying an API in the cloud, update it quickly, and retrieve logs without leaving your favourite IDE!
React Advanced Conference 2021React Advanced Conference 2021
30 min
Building Dapps with React
Decentralized apps (dApps) are continuing to gain momentum in the industry. These developers are also now some of the highest paid in the entire trade. Building decentralized apps is a paradigm shift that requires a different way of thinking than apps built with traditional centralized infrastructure, tooling, and services – taking into consideration things like game theory, decentralized serverless infrastructure, and cryptoeconomics. As a React developer, I initially had a hard time understanding this entirely new (to me) ecosystem, how everything fit together, and the mental model needed to understand and be a productive full stack developer in this space (and why I would consider it in the first place). In this talk, I'll give a comprehensive overview of the space, how you can get started building these types of applications, and the entire tech stack broken apart then put back together to show how everything works.
React Summit 2020React Summit 2020
25 min
Building Real-time Serverless GraphQL APIs on AWS with TypeScript and CDK
CDK (Cloud development kit) enables developers to build cloud infrastructure using popular programming languages like Python, Typescript, or JavaScript. CDK is a next-level abstraction in infrastructure as code, allowing developers who were traditionally unfamiliar with cloud computing to build scalable APIs and web services using their existing skillset, and do so in only a few lines of code.
In this talk, you’ll learn how to use the TypeScript flavor of CDK to build a hyper-scalable real-time API with GraphQL, Lambda, DynamoDB, and AWS AppSync . At the end of the talk, I’ll live code an API from scratch in just a couple of minutes and then test out queries, mutations, and subscriptions.
By the end of the talk, you should have a good understanding of GraphQL, AppSync, and CDK and be ready to build an API in your next project using TypeScript and CDK.
DevOps.js Conf 2021DevOps.js Conf 2021
33 min
Automate React Site Deployments from GitHub to S3 & CloudFront
In this talk, I will demonstrate how to create a CI/CD pipeline for a React application in AWS. We'll pull the source code from GitHub and run tests against the application before deploying it to an S3 bucket for static site hosting. The site will then be distributed using CloudFront which will point to the S3 bucket. All of the infrastructure will be built using Terraform. In addition, I'll make use of Terragrunt to show how to create this setup for multiple environments.

Workshops on related topic

DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
Node Congress 2021Node Congress 2021
245 min
Building Serverless Applications on AWS with TypeScript
Workshop
This workshop teaches you the basics of serverless application development with TypeScript. We'll start with a simple Lambda function, set up the project and the infrastructure-as-a-code (AWS CDK), and learn how to organize, test, and debug a more complex serverless application.
Table of contents:        - How to set up a serverless project with TypeScript and CDK        - How to write a testable Lambda function with hexagonal architecture        - How to connect a function to a DynamoDB table        - How to create a serverless API        - How to debug and test a serverless function        - How to organize and grow a serverless application


Materials referred to in the workshop:
https://excalidraw.com/#room=57b84e0df9bdb7ea5675,HYgVepLIpfxrK4EQNclQ9w
DynamoDB blog Alex DeBrie: https://www.dynamodbguide.com/
Excellent book for the DynamoDB: https://www.dynamodbbook.com/
https://slobodan.me/workshops/nodecongress/prerequisites.html
React Summit 2022React Summit 2022
107 min
Serverless for React Developers
WorkshopFree
Intro to serverlessPrior Art: Docker, Containers, and KubernetesActivity: Build a Dockerized application and deploy it to a cloud providerAnalysis: What is good/bad about this approach?Why Serverless is Needed/BetterActivity: Build the same application with serverlessAnalysis: What is good/bad about this approach?
DevOps.js Conf 2024DevOps.js Conf 2024
59 min
Frontend to the Cloud Made Easy - A ReactJS + AWS Workshop
Workshop
This workshop enables you to learn how to develop React applications, and then deploy them to the cloud (or building them to the console) coupled with a backend, fully abstracted, with no complex backend configuration, simplifying the building and deployment of frontend & web apps to the cloud.
GraphQL Galaxy 2021GraphQL Galaxy 2021
143 min
Building a GraphQL-native serverless backend with Fauna
WorkshopFree
Welcome to Fauna! This workshop helps GraphQL developers build performant applications with Fauna that scale to any size userbase. You start with the basics, using only the GraphQL playground in the Fauna dashboard, then build a complete full-stack application with Next.js, adding functionality as you go along.

In the first section, Getting started with Fauna, you learn how Fauna automatically creates queries, mutations, and other resources based on your GraphQL schema. You learn how to accomplish common tasks with GraphQL, how to use the Fauna Query Language (FQL) to perform more advanced tasks.

In the second section, Building with Fauna, you learn how Fauna automatically creates queries, mutations, and other resources based on your GraphQL schema. You learn how to accomplish common tasks with GraphQL, how to use the Fauna Query Language (FQL) to perform more advanced tasks.