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

♪♪ ¡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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.