De 1 a 101 Funciones Lambda en Producción: Evolucionando una Arquitectura Serverless

Rate this content
Bookmark
32 min
24 Jun, 2021

Video Summary and Transcription

Vacation Tracker es una startup serverless que utiliza Node.js y que comenzó con una simple función lambda y ahora tiene muchas funciones lambda. Construyeron un sistema conectado a Slack y calendarios, que ahora es utilizado por muchas startups, empresas y organizaciones. Han evolucionado hacia una arquitectura basada en eventos utilizando CQRS y AWS AppSync con Managed GraphQL. La incorporación de nuevos desarrolladores es un desafío, pero serverless les permite asignar un nuevo entorno y cuenta de AWS a cada desarrollador. Las pruebas y el monitoreo son cruciales, y han migrado con éxito de MongoDB a DynamoDB.

Available in English

1. The Story of Vacation Tracker

Short description:

¡Hola! Te contaré la historia de Vacation Tracker, una startup sin servidor que utiliza Node.js. Todo comenzó con una simple función lambda, y ahora tenemos muchas funciones lambda. En 2016, decidimos resolver nuestro propio problema de seguimiento de días de vacaciones y días restantes. En 2018, recibimos solicitudes para una versión beta privada y decidimos construir un sistema conectado a Slack y calendarios. Muchas startups, empresas y organizaciones ahora utilizan nuestro sistema.

♪♪ ¡Hola! Te contaré la historia de la startup serverless. La parte serverless definitivamente no es la parte más importante de nuestra startup, pero por otro lado, es una historia realmente genial para alguien que es programador y trabaja con Node.js y otras tecnologías.

Así que te contaré la historia de Vacation Tracker. Como dije, en este momento somos una startup serverless al 100% que utiliza Node.js, pero todo comenzó con una simple función lambda. Luego agregamos otra y otra y otra. Y sí, eso escaló rápidamente. Así que ahora tenemos muchas funciones lambda, y trataré de guiarte a través de nuestra historia desde la primera función lambda hasta el estado actual en producción, y comenzamos hace más de tres años.

Entonces, primero en 2016, decidimos construir un sistema de seguimiento en vivo. En realidad, estoy mintiendo. Decidimos resolver nuestro propio problema porque nuestra otra empresa, Cloud Horizon, tenía más de 10 personas en ese momento. Y era realmente difícil hacer un seguimiento de quién está fuera, cuántos días de PTO les quedan para este año, y cosas así. Construimos... Intentamos hacer un Hackathon interno, y como todos los Hackathons, no construimos nada. Así que en 2017, intentamos construir, resolver nuestro propio problema. Intentamos encontrar algunas otras herramientas de seguimiento en vivo, pero la mayoría de ellas eran como sistemas de recursos humanos complejos y cosas así. Así que decidimos construir algo interno, y creamos una especie de prueba de concepto con Slack. Y como siempre, decidimos no continuar en ese momento, pero publicamos la página de inicio.

En 2018, recibimos muchas solicitudes a través de nuestra página de inicio, más de cien personas esperaron en las listas de espera para una versión beta privada, así que finalmente decidimos construir algo. La idea era realmente simple. Queríamos un sistema que rastreara las solicitudes de vacaciones y el número de días restantes. Queríamos usar algún tipo de inicio de sesión único para no tener que recordar más contraseñas. Odio las contraseñas. Queríamos que algo estuviera conectado a nuestro Slack para poder ver la información cuando la necesitáramos. Por ejemplo, cuando alguien no está trabajando, queremos ver que esa persona está de vacaciones y cosas así. Y finalmente, queríamos conectar nuestro calendario para poder suscribirnos a eventos y ver quién no trabajará el próximo mes y cosas así.

Como dije, estábamos resolviendo nuestros propios problemas y no sabíamos si alguien más usaría nuestro sistema pero unos meses después de lanzar la versión beta, vimos que hay muchas startups que quieren usar nuestro sistema. Y luego vimos algunas pequeñas empresas registrándose y luego algunas escuelas y universidades y luego organizaciones sin fines de lucro y luego equipos de muchas empresas. Y luego vimos algunas organizaciones gubernamentales y vimos algunas otras organizaciones como iglesias y muchas otras organizaciones que nunca pensaron que usarían el sistema de esta manera. Así que había un problema real y decidimos continuar con esa idea. Y hoy tenemos muchos clientes de muchas empresas grandes y famosas y también muchas startups geniales y empresas más pequeñas y organizaciones.

2. The Product and Serverless Architecture

Short description:

El número de usuarios únicos en nuestro sistema el 1 de diciembre fue este. Aquí está el producto: Panel web para cuotas y ubicaciones, integración con Slack para solicitudes de permisos y integración con Microsoft Teams con panel incrustado. Nuestra primera arquitectura fue un simple bot sin servidor, versión 0.1. Permítanme presentarme: Soy Slobodan Stojanovic, CTO de CloudHorizon y Vacation Tracker. Elegimos sin servidor debido a la escalabilidad automática, la conmutación por error automática y la rentabilidad. Fue rápido construir un prototipo utilizando sin servidor.

El número de usuarios únicos en nuestro sistema el 1 de diciembre fue este. No todos estos usuarios están utilizando Vacation Tracker, pero todos estos usuarios pasaron por Vacation Tracker en algún momento. Es un buen número, pero fue un número real que saqué de nuestra base de datos. Decidí dejar este número del 1 de diciembre porque estoy bastante seguro de que no podré obtener este buen número nuevamente.

Entonces aquí está el producto. Tenemos un panel web donde puedes hacer muchas cosas, como ver las cuotas y configurar ubicaciones y muchas otras cosas. Para los usuarios de Slack, también tenemos una integración agradable donde puedes hacer clic en un botón o usar el comando /vacation y solicitar o aprobar el permiso. Para Microsoft Teams, tenemos lo mismo más algunas cosas geniales, como un panel incrustado dentro de Microsoft Teams para que no necesites iniciar sesión en un sistema separado y cosas así. Pero hablemos de cosas interesantes y eso es la arquitectura, no el sistema en sí.

Entonces nuestra primera arquitectura fue un simple bot sin servidor. Esta fue la versión 0.1 porque era mejor y no sabíamos si alguien usaría nuestro sistema. El bot se veía algo así. Fue realmente divertido porque no había calendario ni nada parecido dentro de Slack, así que construimos todo con botones, pero parece que eso fue mejor que las hojas de cálculo de Excel y muchas otras cosas que la gente usa para hacer un seguimiento de sus permisos. Y cada vez que haces clic en este botón o algo así, activa un bot sin servidor en segundo plano.

Entonces, ¿por qué sin servidor? Esa es la primera pregunta obvia. Bueno, esta charla trata sobre escalar una startup sin servidor de 1 a 10001, aún no 1000. 101 funciones Lambda en producción, por eso. Estoy bromeando, por supuesto, pero ahora que han detenido el flujo, permítanme presentarme. Soy Slobodan Stojanovic. Soy CTO de CloudHorizon y también CTO de este producto, Vacation Tracker. También soy coautor del libro Aplicaciones sin servidor con Node.js, que escribí con mi amigo Aleksandar Simovic. Y también soy un héroe sin servidor de AWS. Escribo mucho sobre sin servidor y puedes ver más artículos en mi sitio web. Hay enlaces a muchos otros sitios web donde escribo sobre sin servidor. Pero volvamos a la pregunta más importante, ¿por qué sin servidor? Como probablemente sabes, sin servidor es un acrónimo de algo como lento, costoso, bloqueo de proveedor, y obviamente estoy bromeando, eso no es cierto. Realmente me encanta sin servidor y decidimos construir todo con sin servidor porque en el momento en que comenzamos esto, éramos un equipo pequeño, todavía somos un equipo pequeño, y nuestro equipo no tenía mucha experiencia en DevOps. Así que decidimos usar algo que tuviera escalabilidad automática y conmutación por error automática como esta. Intentamos ser lo más económicos posible porque financiamos nuestra startup, por lo que sin servidor se ajusta muy bien porque es económico. Y fue realmente rápido construir un prototipo utilizando sin servidor. Nos llevó unos días construir ese chatbot con ese calendario falso y todo eso.

3. Building a More Complicated Serverless Application

Short description:

Y estaba listo para producción, básicamente. Nuestra primera versión no era 100% sin servidor. Decidimos agregar nuevas características. Nos enfrentamos al primer problema con nuevos puntos finales. Nuestra base de datos MongoDB no era sin servidor. Intentamos construir una aplicación sin servidor más complicada introduciendo infraestructura como código.

Y estaba listo para producción, básicamente. Y, por supuesto, serverless también nos brinda un buen punto de partida para la security. Por supuesto, aún debes pensar en tus data y todo, pero las funciones Lambda son seguras por sí mismas y es realmente fácil asegurar algo que está activo durante, digamos, 100 milisegundos o algo así.

Por supuesto, nuestra primera versión no era 100% serverless. Comenzamos como un chatbot serverless. Entonces Slack envía algunas solicitudes a algún tipo de puerta de enlace de API. En realidad, se llama Amazon API Gateway, que activa alguna función Lambda con cierta lógica empresarial. Y ese fue nuestro prototipo. Pero luego decidimos construir algún backend para eso porque queremos que las personas puedan almacenar los data y que esta aplicación haga algo significativo. Y luego construimos algún tipo de aplicación Angular y el desarrollador al que asignamos este proyecto no conocía serverless. Así que decidió usar Node.js y el servidor Express.js y MongoDB. Entonces, la mitad de nuestro producto era serverless y el resto era básicamente una aplicación tradicional estándar.

Hubo algunos beneficios claros de esto. Fue rápido e independiente, las implementaciones fueron rápidas e independientes y fue fácil de entender y mantener este tipo de aplicación porque, como viste, solo había unos pocos componentes en el sistema, fue fácil incorporar a nuevas personas porque es fácil explicar cómo funciona la aplicación y todo era realmente barato. El costo del primer año para nosotros fue cero dólares al mes para AWS. Teníamos algunos créditos para MongoDB y nuestro servidor pero la parte serverless era en realidad cero dólares al mes durante mucho tiempo porque te cobran según el número de solicitudes y el primer año no tuvimos suficientes solicitudes para comenzar a pagar algo a AWS.

Luego decidimos agregar algunas nuevas características porque la gente las solicitaba y nuestro desarrollador aprendió serverless y trató de usar serverless para las nuevas características por lo que todas las nuevas características pasaron por esa puerta de enlace de API y luego, por ejemplo, para la facturación agregamos una nueva función Lambda conectada a Stripe y agregamos algunos nuevos puntos finales y cosas así. Pero para los nuevos puntos finales nos enfrentamos al primer problema. Nuestra aplicación Angular necesita saber dónde está ese punto final ¿Está en la aplicación Express.js o dentro de alguna función Lambda? Así que intentamos hacer algo como esto. En lugar de ir directamente al servidor Express.js usamos la puerta de enlace de API como una puerta de enlace para todo. Y, sí, eso fue un poco confuso y tenía desventajas para cada parte del sistema que requería implementaciones independientes. Fue difícil administrar todo porque teníamos más y más funciones Lambda, era difícil escalar estas debido a este tipo de sistema y teníamos un cuello de botella claro. Nuestra base de datos MongoDB no era serverless, por lo que todo lo demás se escalaba excepto esa parte. En ese momento teníamos alrededor de cien equipos de pago por lo que decidimos mejorar nuestra architecture porque parece que la gente quiere este tipo de producto. Así que intentamos construir una aplicación serverless más complicada. El primer paso fue introducir la infraestructura como código. Usamos CloudFormation e intentamos tener diferentes servicios dentro de esa CloudFormation. Entonces, por ejemplo, cuando haces algo en un servicio ese servicio puede enviar algo a la, digamos API del otro servicio, pero esa API no necesita ser una puerta de enlace de API o una API RESTful. A veces es algún tipo de interfaz para notificaciones que se pueden enviar en segundo plano. Por ejemplo, esta parte del sistema sigue siendo la misma.

4. Handling Slack Messages and Architecture Migration

Short description:

Recibimos mensajes de Slack a través de nuestra puerta de enlace de API, lo que desencadena funciones Lambda según las acciones del usuario. Utilizamos Amazon EventBridge para las notificaciones y tenemos lógica empresarial que maneja los datos. Con 150 funciones Lambda, migramos de los antiguos servicios Express a los nuevos servicios sin servidor. Adoptamos una arquitectura hexagonal, realizamos cambios en CloudFormation, cambiamos a servicios sin servidor, agregamos TypeScript y reemplazamos MongoDB con DynamoDB.

Cada vez que recibimos un mensaje de Slack o algo similar, eso va a nuestra puerta de enlace de API. Desencadena algunas funciones Lambda según la acción que el usuario esté utilizando, ya sea un comando de barra diagonal o hacer clic en un botón y cosas así. Luego usamos algo llamado Amazon EventBridge para enviar notificaciones en segundo plano. Y respondemos a Slack y le decimos a Slack que el mensaje ha sido recibido. Y luego tenemos lógica empresarial en algún lugar en segundo plano haciendo algo con esos data.

En ese momento, teníamos 150 funciones Lambda, lo cual era mucho. Y comenzamos a hacer nuestras primeras migraciones. Teníamos servicios antiguos en Express y luego construimos nuevos servicios sin servidor y de alguna manera migramos a los usuarios para que usen los otros servicios. Y una de las partes clave de esto fue encontrar una buena arquitectura. Elegimos una arquitectura hexagonal, pero hablaremos de eso un poco más adelante. Cambiamos todo dentro de CloudFormation. Reemplazamos el servidor NodeJS con servicios sin servidor aún con NodeJS. Comenzamos a agregar TypeScript y reemplazamos MongoDB con DynamoDB. No para todo, pero para la mayoría de las cosas.

5. Evolution to Event-Driven Architecture

Short description:

Beneficios: implementación más fácil, casi un 100% de tiempo de actividad y rentabilidad. Desventajas: almacenamiento de estado, pérdida de tiempo en lógica no relacionada con el negocio, dificultades de incorporación y desagrado de los desarrolladores por YAML y configuración. Evolucionamos a una arquitectura basada en eventos utilizando CQRS para almacenar eventos. Utilizamos AWS AppSync con Managed GraphQL para mutaciones, almacenamiento de eventos, lógica en segundo plano, suscripciones en tiempo real y consultas rápidas.

Los beneficios fueron que era más fácil implementar nuestra aplicación. Aún no era escalable. Hasta ahora, hemos tenido casi un 100% de tiempo de actividad de forma predeterminada. No hicimos nada para lograr eso. Estuvimos inactivos durante, creo, 30 minutos en total desde 2018 y aún así fue muy económico. Las desventajas eran que almacenábamos estado, no eventos. Perdíamos mucho tiempo en, sin enfocarnos en nuestra lógica empresarial, sino en otras partes del sistema. Era difícil incorporar nuevos desarrolladores debido a los muchos servicios nuevos. Y me di cuenta de que a los desarrolladores no les gusta YAML y la configuración. En ese momento teníamos alrededor de 600 equipos de pago.

Así que decidimos evolucionar nuestra architecture una vez más. Y decidimos utilizar una arquitectura basada en eventos. Volvimos a la mesa de dibujo y tratamos de encontrar otra buena architecture que funcionara con la architecture hexagonal y nos ayudara a resolver nuestro problema. Y decidimos utilizar Command Query Responsibility Segregation o CQRS. ¿Por qué CQRS? Como dije, estábamos almacenando estado, pero queríamos almacenar eventos. ¿Por qué eventos? Porque Vacation Tracker es muchas cosas que suceden todo el tiempo. Por ejemplo, alguien puede agregarte a una asignación, asignar una política de licencia, agregar días de licencia para ti. Puedes solicitar una licencia. Alguien puede cambiar tu fin de semana de trabajo. Muchas cosas suceden en cada momento. Y la pregunta siempre es cómo calcular los días restantes de PDO para el año actual u otros días para el año actual con los data que tenemos. Y, por supuesto, almacenar eventos nos ayuda mucho, pero terminamos.

Decidimos eliminar parte de nuestro código. Así que decidimos utilizar AWS AppSync con Managed GraphQL. AppSync es básicamente un servicio de Managed GraphQL. Ahora, cada vez que un panel de control u otra aplicación escribe algo, cambia algo en nuestra aplicación, envía una mutación. Almacenamos esa mutación en una tabla de almacenamiento de eventos que desencadena alguna lógica en segundo plano. Realizamos alguna lógica empresarial. Utilizamos suscripciones en tiempo real para que el front-end sepa que la lógica empresarial está lista. Y también almacenamos algún tipo de estado, estado actual en algunas tablas de solo lectura porque queremos que los usuarios puedan ejecutar consultas muy rápidas utilizando GraphQL desde el front-end.

6. Challenges of Onboarding and Testing

Short description:

En este momento, tenemos 112 funciones Lambda. Tenemos un servidor GraphQL totalmente administrado que funciona muy bien. El sistema es más rápido, con menos código y un mejor control. Ahora tenemos un repositorio único, que permite compartir código entre el frontend y el backend. La incorporación de nuevos desarrolladores es un desafío, pero el uso de serverless nos permite asignar un nuevo entorno y una cuenta de AWS a cada desarrollador. Comenzamos con una pequeña parte del sistema e introducimos gradualmente nuevas características. Las pruebas son importantes y utilizamos la arquitectura hexagonal para aislar la lógica empresarial de los adaptadores. Probamos localmente y utilizamos adaptadores de eventos de lambda en producción.

En este momento, tenemos 112 funciones Lambda. Como puedes ver, hemos eliminado algunas de las funciones Lambda y hay algunos beneficios claros. Tenemos un servidor GraphQL totalmente administrado que funciona muy bien. El sistema es realmente más rápido. Tenemos menos código, tenemos un mejor control y, por supuesto, tenemos todos los beneficios de la antigua arquitectura.

Ahora tenemos un repositorio único, lo cual parece ser una gran ventaja porque compartimos código entre el frontend y el backend. Todavía hay muchos servicios para aprender y hay plantillas de velocidad. Ahora, en lugar de algunas funciones y plantillas de velocidad, ni siquiera intentaré explicar. Estos son como un lenguaje alienígena donde transformas la solicitud en algo que AppSync comprende. Y así no necesitamos tener una función Lambda entre la solicitud en sí y la tabla de eventos. Y eso nos ayuda a mejorar la velocidad de nuestro sistema en este momento. Pero, por supuesto, hay muchos desafíos en este proceso.

El primer desafío obvio es cómo incorporar a nuevos desarrolladores. Nuestra cosa actual tiene solo cuatro desarrolladores, todos de pila completa y uno es nuevo, uno de los desarrolladores acaba de comenzar. Tenemos una persona de marketing, una persona de soporte al cliente, un gerente de producto y tenemos algún soporte independiente para marketing y diseño principalmente. Lo bueno de serverless es que podemos asignar el nuevo entorno y la nueva cuenta de AWS a cada desarrollador. Entonces, el primer día que te unes a Vacation Tracker, obtendrás una copia básicamente de todo dentro de la cuenta de AWS que te pertenece solo a ti. Y como el sistema es realmente complejo, este es el mismo diagrama que vimos anteriormente pero con un poco más de detalles. No comenzamos con todo de inmediato, comenzamos con solo una pequeña cosa, por ejemplo, un nuevo desarrollador comienza a trabajar con nuestro panel en línea, que es básicamente una aplicación React, y luego lentamente con las nuevas características que están agregando o cambiando dentro del panel, comienzan a aprender el backend y cómo funciona todo en el backend, y luego continúan usando y aprendiendo diferentes partes de nuestra aplicación. Y después de aproximadamente tres meses, conocen básicamente la mayoría de las partes del sistema. No los detalles, por supuesto, pero saben cómo funciona todo.

Las pruebas fueron otro gran desafío y son realmente importantes y ahora podemos hablar sobre la arquitectura hexagonal, puertos y adaptadores. Básicamente, nuestra lógica empresarial está aislada de todos los diferentes adaptadores. Entonces podemos probar todo localmente con un disparador local y luego ejecutar todo con adaptadores de eventos de lambda en producción. Volvamos a este ejemplo y centrémonos en esta función. El código se ve algo así ahora con TypeScript, pero este era un ejemplo de JavaScript. Por ejemplo, hay un archivo lambda.js para cada servicio que no hace nada excepto disparar las dependencias. Hay un main.js que es básicamente una lógica empresarial que tiene sus propias pruebas unitarias e integradas, pero muchas partes de nuestro sistema están utilizando algunos repositorios comunes, por ejemplo, enviando eventos a ese puente de eventos. Entonces, no queremos probar cada función contra el puente de eventos, en su lugar tenemos un repositorio de notificaciones local con la misma interfaz, es fácil hacerlo con TypeScript.

7. Testing, Debugging, and Monitoring

Short description:

Luego tenemos un repositorio real de Event Bridge y algunos otros repositorios que tienen sus propias pruebas unitarias e integradas. Utilizamos repositorios de MongoDB y DynamoDB con pruebas unitarias e integradas. La depuración y el monitoreo son desafíos. El costo total desde 2018 fue de $7,000, pero tuvimos algunos créditos de AWS. El error más costoso fue con DynamoDB y solucionarlo redujo los costos en cientos de dólares al mes. Estamos contentos con Serverless y tenemos un equipo de desarrolladores superhéroes. Evoluciona tu arquitectura con tu producto y considera la incorporación de nuevos miembros al equipo.

Luego tenemos un repositorio real de Event Bridge y algunos otros repositorios que tienen sus propias pruebas unitarias e integradas y los estamos probando contra los recursos reales de AWS. Y, por supuesto, tenemos algunas funciones y servicios auxiliares que tienen, por ejemplo, un analizador de eventos que tiene sus propias pruebas unitarias, no de integración, porque no está integrado con nada. Y para las migraciones hacemos algo como esto. Utilizamos ese repositorio de MongoDB o parte de él con sus pruebas unitarias e integradas. Intentamos construir otro repositorio con la misma interfaz, por ejemplo, para DynamoDB. Y luego, cuando tenemos la misma interfaz, simplemente podemos cambiar la dependencia en producción. Por supuesto, además de eso, necesitas transferir los datos, pero eso es otro tema.

Entonces, probar las cosas en integración se ve algo como esto. Por ejemplo, si quiero probar el repositorio de DynamoDB y quiero hacer pruebas de integración, puedo crear una base de datos antes de todas las pruebas y destruirla después de todas las pruebas simplemente haciendo algunos comandos simples y esperando unos 10 a 20 segundos más 20 segundos para crear una nueva tabla. Y luego, al final, simplemente queremos destruir esa tabla para no dejar basura en nuestras cuentas de AWS. Esta cuenta es solo para pruebas, pero de todos modos queremos eliminar todo al final. Y eso es todo. Otro gran desafío que tuvimos fue la depuración y el monitoreo. Y ahora podemos ejecutar diferentes tipos de consultas ya que tenemos todos los errores en nuestro sistema y cosas como estas, tenemos diferentes paneles de control que nos ayudan a monitorear nuestra aplicación y recibir alertas y cosas así. Por supuesto, el costo es otro gran desafío con Serverless, pero el costo total desde 2018 fue de $7,000. Y, por supuesto, tuvimos algunos créditos de AWS. Entonces, pagamos tal vez $2,000 hasta ahora. En realidad, calculé el error más costoso. Como puedes ver, es la mitad de la factura que tuvimos desde el principio. Y el error fue con DynamoDB. Como puedes ver, cuando solucionamos el error, el número de solicitudes de miles de solicitudes por minuto cayó prácticamente a cero. Y eso redujo mucho los costos, como cientos de dólares al mes. Y, por supuesto, tuvimos muchos otros desafíos más pequeños, pero estamos muy contentos con Serverless hasta ahora. No están relacionados tanto con Serverless. Son desafíos generales que tienes al construir una startup de todos modos. Y ahora, con Serverless, tenemos un equipo de desarrolladores realmente superhéroes que pueden desarrollar muchas cosas muy rápido.

Entonces, eso es todo, repasemos un resumen rápido porque esto fue un poco más largo de lo que esperaba. Debes evolucionar tu arquitectura con tu producto. Algo que funcionó al principio no puede funcionar ahora que nuestro producto es mucho más grande y diferente. Necesitas elegir una buena arquitectura porque te ayuda a mantener bajos o razonables los costos de migración e incorporación.

8. Onboarding, Architecture, Testing, and Monitoring

Short description:

La incorporación de nuevos miembros al equipo es importante. La arquitectura hexagonal y CQRS son buenas opciones para serverless. Las pruebas y el monitoreo son cruciales. Suscríbete a mi sitio web para obtener más información sobre serverless.

Debes pensar en la incorporación de nuevos miembros al equipo porque esa es una parte realmente importante de cada sistema. La arquitectura hexagonal es muy adecuada para aplicaciones serverless porque te ayuda a probar todo. CQRS también es una buena opción para serverless pero también es una excelente opción para nuestro producto. Encuentra algo que funcione para ti.

Debes probar tus integraciones y la aplicación en general, por supuesto y las pruebas no siempre son suficientes. Debes monitorear tu aplicación y rastrear los errores para poder reaccionar rápidamente si algo se rompe. Y eso es todo. Muchas gracias. Escribo mucho sobre serverless. Estoy haciendo algunos talleres gratuitos y cosas así. Si quieres seguir más sobre estas arquitecturas y lo que estamos haciendo con serverless, puedes suscribirte en mi sitio web. Muchas gracias.

QnA

Serverless Adoption and Fender Locking

Short description:

El 61% aún no está utilizando serverless. Eso significa que el 40% de las personas han utilizado serverless en algún momento, lo cual es realmente bueno. En los últimos años, el porcentaje ha aumentado del cero al 40%. Si volvemos a hacer esta pregunta el próximo año, estaré feliz de ver que el 50 al 60% de las personas están probando serverless. No es la solución para todo, pero se puede utilizar para muchos casos de uso diferentes. Abordemos una pregunta del público sobre el bloqueo de proveedores. No tengo miedo al bloqueo de proveedores porque es simplemente un costo de cambio cuando decides usar algo nuevo.

Me alegra verte. ¿Qué opinas? El 61% aún no está utilizando serverless. ¿Qué está pasando? Oh, está bien. Está bien. Eso es algo que esperaba. Y está bien. Creo que el 40% de las personas que utilizan serverless en algún momento, al menos para una pequeña parte de su aplicación, es realmente bueno. Aún es bastante nuevo y hay muchas cosas nuevas que debes aprender para poder usar serverless en tu aplicación. Sí, creo que es un buen porcentaje. Y en los últimos años, he visto que el porcentaje ha aumentado de algo cercano a cero al 40%. Así que sí, eso es genial. Si volvemos a hacer esta pregunta el próximo año, ¿qué porcentaje esperarías entonces? No lo sé, un poco más del 40%. Así que estaré feliz si veo, digamos, que el 50 al 60% de las personas al menos están probando serverless. Al menos mojando los pies en el agua, ¿verdad? Sí. Muy bien, entonces. No es la solución para todo, pero hasta ahora creo que se puede usar serverless para muchos casos de uso diferentes, y cada día cubren más y más cosas. Así que sí, muy bien.

Veamos las preguntas del público. La primera pregunta es de House of Hala Handebo. Comienza su pregunta con `charla impresionante` y luego un emoji de confeti. Así que eso es bueno. Algunos comentarios agradables de House of Hala Handebo. Y su pregunta es, ¿cuáles son tus impresiones generales sobre el bloqueo de proveedores cuando usamos proveedores específicos de serverless? Este es un tema que ha surgido varias veces ayer, el bloqueo de proveedores, ¿cómo te sientes al respecto? Sí, esta es una de las preguntas más importantes relacionadas con serverless, y realmente no tengo miedo al bloqueo de proveedores, porque para mí, eso es simplemente un costo de cambio. Cada vez que decides usar algo, digamos Node.js o PHP o Ruby on Rails. Vi que alguien mencionó que somos una pequeña startup que no utiliza Ruby on Rails, y sí. Básicamente, cada vez que decides usar algo, tienes algunos costos de cambio. Si necesitas migrar a algo más en el futuro, deberás dedicar tiempo y pagar una cierta cantidad de dinero para migrar a otra cosa.

Benefits, Migrations, and Onboarding

Short description:

Serverless nos brinda grandes beneficios, especialmente para las startups. La migración de servicios es un riesgo empresarial, pero hemos migrado con éxito de MongoDB a DynamoDB. Cada decisión tecnológica tiene costos de cambio. Incorporar personas sin experiencia es factible. Comenzamos con tareas simples e introducimos gradualmente más servicios. Incluso estamos ofreciendo un taller para aprender aplicaciones serverless con TypeScript.

Y es lo mismo con serverless. Hasta ahora, serverless nos está brindando grandes beneficios, especialmente para las startups, el tiempo que necesitas para construir algo es más importante que otras cosas. Estoy bien si necesito migrar algunos servicios de serverless a otra cosa en el futuro, pero no veo por qué tendría que hacerlo. Tendré que pagar algo de dinero y dedicar tiempo a eso, pero está bien, es un riesgo empresarial que estoy dispuesto a asumir. Ya hemos migrado muchas cosas diferentes, por ejemplo, usamos MongoDB y migramos a DynamoDB, así que eso fue un gran cambio. No creo que migrar de otros recursos de AWS a algo que no esté en AWS sea mucho más complejo que eso.

Así que sí, una perspectiva divertida que mencionaste es que incluso el lenguaje de programación es una especie de bloqueo. Nunca lo había pensado realmente. También los frameworks y muchas otras cosas, realmente depende, por ejemplo, cada vez que te comprometes con algo, básicamente, cada vez que decides hacer algo con tu producto, tienes algunos costos de cambio relacionados con eso, incluso incorporar personas es una especie de bloqueo cuando usas diferentes servicios, debes cambiar tus procedimientos de incorporación y muchas otras cosas. Y sí, es difícil. Sí, nunca lo había pensado así, pero cada decisión que tomas en cuanto a tecnología es una especie de bloqueo. No es genial.

La siguiente pregunta es de William RJ Ribeiro. Lo que puedo imaginar es que es difícil encontrar personas que ya tengan experiencia con serverless, ¿cómo incorporas a nuevas personas que no tienen experiencia? Sí, eso es lo que estamos haciendo ahora mismo. Comenzamos hace unas semanas y nuestro nuevo miembro del equipo, Ivan, lanzó su primera función en producción en su segunda semana en Vacation Tracker. Supongo que no está mal. Por ejemplo, él tiene experiencia con React. Comenzamos con tareas de frontend y React, y luego lentamente comenzó a asumir algunas tareas que tienen algunas características backend y cosas así. Y estamos tratando de incorporar a las personas a algunos servicios más simples que puedan entender fácilmente. Por ejemplo, tienes una API, tienes una función Lambda, que básicamente es una especie de controlador, y luego en el otro lado tienes alguna llamada a la base de datos o algo así. Y luego, cuando aprenden a hacer eso, lentamente agregamos más servicios y tratamos de mostrarles la parte del panorama general de nuestra arquitectura en la que están trabajando. Y con el tiempo, podemos incorporar a personas sin experiencia en serverless a Vacation Tracker sin grandes dificultades. Fue más difícil para mí incorporar personas a proyectos que no son serverless que ahora a proyectos serverless. Lleva tiempo y hay una curva de aprendizaje, pero se puede hacer, no es muy diferente de otras cosas. Entonces, básicamente estás diciendo que incluso podrías enseñarme. Claro. Sí, podemos hacerlo después de esta charla. Necesitamos una fiesta posterior. En realidad, tengo una mejor idea. Si alguien quiere aprender serverless, estamos haciendo un taller la próxima semana como parte de esta conferencia, para que puedas aprender cómo escribir aplicaciones serverless con TypeScript.

Testing Lambda Functions in Production

Short description:

Puedes probar las funciones lambda en un entorno de producción utilizando la misma función en un entorno de preparación y promoviéndola a producción sin necesidad de volver a implementarla. Serverless permite crear entornos nuevos a bajo costo que se pueden duplicar para cada desarrollador. Configurar un entorno de preparación y duplicar y anonimizar los datos puede ser desafiante pero no está relacionado con serverless. En general, serverless facilita y abarata tener entornos que funcionen y se escalen de la misma manera que la producción.

Sí, esa es una de las opciones. Muy bueno también. Entonces, William, eso está incluido en el precio de tu entrada, como mencionamos en la apertura. Asegúrate de ver el taller de Slobodan.

Tenemos tiempo para una pregunta y esa pregunta es de Perry. Gran panel de discusión en el que participaste ayer y también la charla de hoy. ¿Es posible probar las funciones lambda en un entorno de producción? Oh sí, lo es. Además, hay una buena cosa con las funciones lambda es que puedes usar exactamente la misma función lambda en, por ejemplo, un entorno de preparación, probar esa función y simplemente etiquetar esa función con una etiqueta de producción o algo así. Ese mismo código sin necesidad de volver a implementarlo se promoverá a producción. No estoy usando eso en este momento, pero incluso puedes hacer eso, pero sí, claro.

Lo bueno de serverless es que los nuevos entornos no son tan costosos y la mayoría de las veces son en realidad $0 así que tenemos un entorno por desarrollador que es exactamente igual que la producción. No tienen los mismos datos, pero podemos llenar esa base de datos con los mismos datos si queremos. Pero sí, es como, por supuesto que puedes usarlo en producción. Es como cualquier otra cosa. No te preocupas por el servidor en sí. Alguien más se encargará de esa parte del trabajo, pero todo lo demás es completamente factible de la misma manera que lo hiciste para aplicaciones no-serverless. Así que básicamente puedes duplicar tu entorno de producción para convertirlo en un entorno de preparación por desarrollador con un costo bajo. Con casi cero costos, sí. Eso es genial. Eso es genial. Por lo general, configurar un entorno de preparación donde tuvimos una gran charla ayer también sobre la configuración de un entorno de preparación y duplicar datos y generalmente anonimizar datos también, por supuesto. Sí, eso sigue siendo difícil, pero eso no está relacionado con serverless. Eso está relacionado con tus datos. Pero tener todo lo que funciona y se escala de la misma manera es bastante... No diré fácil, pero es más fácil que antes. Y definitivamente más barato. Genial.

Así que eso es todo el tiempo que tenemos para esta sesión de preguntas y respuestas. Si quieres discutir más sobre serverless con Slobodan, Slobodan estará en el chat espacial en su sala de conferencias. Asegúrate de ir allí. Tenemos algunas preguntas más en el canal de preguntas y respuestas, pero no tenemos tiempo para abordarlas ahora. Haré todo lo posible para responder en el chat especial y, por supuesto, en Discord después de esa sesión. Gracias. Muy bien. Ha sido genial tenerte de nuevo, Slobodan. Espero verte de nuevo pronto. Adiós. Adiós. Adiós.

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

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.

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 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.