1. Introducción a las Colas de Mensajes
Hola a todos. Bienvenidos a mi charla sobre confiabilidad, backend y ejecución. Discutiré el paradigma que facilita la vida. Ahora estamos viviendo en una constante nostalgia de los años 90. Los años 90 nos trajeron muchas cosas geniales, pero hay una cosa de la que podríamos despedirnos: las colas. Las colas de mensajes son una forma de comunicación asincrónica entre servicios. Permiten una entrega garantizada y la descarga de procesos de larga duración.
Hola a todos. Bienvenidos a mi charla donde, durante los próximos 20 minutos, hablaré sobre confiabilidad, backend y ejecución. Solo una breve introducción. Mi nombre es Sylvia Vargas. Soy de Polonia. Me encantan los pierogi y anteriormente trabajé en StackBlitz. Ahora soy líder de relaciones con desarrolladores en Ingest. Esta charla trata sobre el paradigma que facilita la vida. Pero antes de hablar de lo bueno, hablemos de lo malo. Ahora estamos viviendo en una constante nostalgia de los años 90. Y, por supuesto, esto no es sorprendente. Los años 90 nos trajeron muchas cosas diferentes, cosas geniales que todavía están con nosotros. Sin embargo, hay una cosa de la que posiblemente podríamos despedirnos. Y estas son las colas. Así que veamos qué son las colas de mensajes. Una cola de mensajes es una forma de comunicación asincrónica entre servicios utilizando una arquitectura de microservicios. Los mensajes se almacenan en la cola hasta que se procesan y se eliminan. Cada mensaje es procesado solo una vez por un único consumidor. Pero aquí necesito interrumpir porque en realidad, varios trabajadores pueden consumir mensajes de una cola. Para preservar el orden de las tareas, deberán ejecutarse en serie. Pero volviendo a la definición ahora. Y las colas de mensajes se pueden usar para desacoplar el procesamiento pesado para almacenar o agrupar trabajos y suavizar las cargas de trabajo pico. Entonces puedes pensar en que una vez que agregas algo a la cola, llegará a su destino uno por uno. La entrega está garantizada. Y lo que sucede en la cola no afecta otras partes de la infraestructura. Y las colas pueden ser realmente masivas. Así que recapitulemos. Con las colas, obtienes entrega garantizada porque sabes que una vez que algo se agrega a la cola, solo la dejará una vez que se procese. Y las colas permiten a los desarrolladores descargar procesos de larga duración al fondo para que tu aplicación no se atasque. Usarías colas para tareas intensivas de datos.
2. Drawbacks of Using Queues
Y otra ventaja de las colas es la escalabilidad horizontal. Sin embargo, hay inconvenientes en el uso de colas. Construir infraestructura adicional y gestionar aplicaciones complejas puede ser mucho trabajo. En tiempos de presupuestos y recursos limitados, vale la pena considerar si gestionar colas es la elección correcta. En cambio, la ejecución duradera nos permite definir la lógica del flujo de trabajo en el código de nuestra aplicación y garantiza una ejecución confiable.
procesos o al integrarse con sistemas externos. Y otra ventaja es la escalabilidad horizontal porque se pueden procesar varios mensajes en paralelo. A medida que aumenta la carga de trabajo, las aplicaciones múltiples pueden manejar un alto rendimiento y seguir siendo confiables. Sin embargo, hay un pero. Así que veamos este comentario de Reddit. Las colas son geniales en procesos intensivos de datos, como dije, que no necesitan ejecutarse en el hilo principal porque se ejecutan de forma asincrónica. Las tareas se procesan en segundo plano y la aplicación sigue siendo receptiva. Sin embargo, hay algunos inconvenientes en las colas, que este usuario de Reddit menciona delicadamente en esta cita. Una vez que tomas algo de la cola, el resto depende de ti. Y el servicio de encolado ya no se preocupa. Entonces, ¿qué significa eso? Veamos eso. Las colas son geniales cuando tu aplicación es simple. Cuando crece en complejidad o si es distribuida, de repente necesitas preocuparte por toda una serie de infraestructura adicional que necesitas construir. Y serás tú quien tenga que construirla. Por ejemplo, deberás construir
concurrency porque quieres poder controlar cuántos pasos se ejecutan al mismo tiempo. O, por ejemplo, debouncing porque todos sabemos lo costoso que es cuando las funciones se ejecutan varias veces. O persistencia y gestión de estado porque ahora que tienes una aplicación distribuida o compleja, debes compartir el estado entre diferentes funciones y colas. Luego también está el manejo de errores porque ¿qué pasa si hipotéticamente un proveedor de servicios tiene una interrupción? Deberás incluir reintentos y también fallos. Quiero decir, reintentos para fallos y también tiempos de espera. Y en ese caso, también necesitas herramientas de recuperación para comprender y procesar los errores y eventos fallidos. Esto ya suena como mucho trabajo y ni siquiera es una lista exhaustiva. Así que no tienes que escucharme a mí en eso. En momentos como este, cuando los presupuestos de ingeniería y las plantillas se reducen, nosotros como desarrolladores e ingenieros individuales debemos hacer más con menos. Entonces, realmente vale la pena preguntarse en este momento, ¿realmente quieres estar en el negocio de gestionar y operar tus propias colas? Bueno, Matthew Druker, el CEO de SoundCloud, no cree que debamos hacerlo. Entonces, si esto es ahora un conocimiento común, ¿por qué la gente sigue usando colas? Bueno, estamos acostumbrados a algo. Se siente familiar y acogedor incluso si no es la solución más acogedora. Puedes hacer que todo funcione con el esfuerzo suficiente. Afortunadamente, hay una mejor solución que se basa en el concepto de colas de mensajes. Entonces, en lugar de separar nuestra infraestructura, como las colas, de nuestro código, ¿qué tal si pudiéramos definir nuestra lógica de flujo de trabajo puramente en nuestro código de aplicación y asegurarnos de que se ejecute de manera confiable? Esto es lo que nos ofrece la ejecución duradera. La ejecución duradera es, como su nombre indica, duradera. Garantiza que nuestro código se ejecute.
3. Additional Functionalities and Real-World Example
Esta parte explica las funcionalidades adicionales proporcionadas por el sistema. También presenta un ejemplo del mundo real de cómo construir un flujo de registro utilizando servicios de terceros, enfatizando la simplicidad y facilidad que ofrece a los desarrolladores.
se completará, incluso si hay fallos en los mensajes en el camino. Por lo tanto, esta parte es la misma que las colas de mensajes. Sin embargo, a diferencia de las colas de mensajes, también obtienes lógica retrospectiva, manejo de errores, o persistencia de estado, que viene integrado. No tienes que construirlo. Se te proporciona.
La otra parte es el control de flujo, que es todo lo demás que se necesita para que puedas ejecutar tus funciones de manera confiable, como concurrency (concurrencia), debouncing, priorización de tareas, manejo de fallos o herramientas de recuperación. Suficiente teoría. Veamos un ejemplo del mundo real. Trabajas en una nueva startup de reservas de restaurantes muy popular. Tu jefe te pregunta cuánto tiempo te llevará construir un flujo de registro. Entonces recibes una lista de requisitos del gerente de productos. Lo miras con un café con leche helado en la mano. Estás completamente tranquilo. Veamos. Necesitas autenticar de forma segura al usuario. Necesitas agregar al usuario a una database (base de datos). Necesitas agregar al usuario a la lista de correo. Y finalmente enviar un correo electrónico de bienvenida. Afortunadamente, construir esto es mucho más fácil hoy en día de lo que hubiera sido hace cinco años. Porque puedes usar Clerk para la autenticación, SupaBase para la base de datos, MailChimp para la lista de correo y Resend para
4. Challenges of Distributed Applications
Construir aplicaciones utilizando servicios de terceros es inteligente y facilita la vida. Sin embargo, hay un inconveniente. A veces, los servicios pueden ser lentos, lo que causa código bloqueante y ralentiza la API. Esto afecta la experiencia del usuario. Gestionar reintentos, registrar errores e implementar un sistema de recuperación añade complejidad y aumenta el tiempo de desarrollo.
email. De acuerdo. Trabajo hecho. Puedes dar un gran sorbo a tu café con leche helado y volver a jugar Wordle o leer uno de esos miles de hilos en Twitter. Entonces, aquí está el
code. Y crearías un usuario en la
database. Enviarías un correo electrónico de bienvenida. Y agregarías al usuario como miembro de una lista de correo. Bueno, esto parece muy simple. Y nos gusta lo simple. ¿Verdad? Somos perezosos como desarrolladores. Construir aplicaciones utilizando servicios de terceros es inteligente y facilita la vida. Así que nos gusta lo fácil. Pero, ¿dónde está el problema? ¿Termina aquí mi presentación? Bueno, no. Hay un inconveniente. Porque ahora hemos creado una aplicación distribuida en la que no tenemos control sobre gran parte de la infraestructura en la que confiamos. Por ejemplo, a veces los servicios pueden ser lentos. Enviar un correo electrónico o incluso en un buen día puede llevar medio segundo. Así que ahora tenemos un problema. Tenemos código bloqueante en el camino crítico de nuestra solicitud. Como resultado, estamos haciendo que nuestra API sea más lenta. En otras palabras, tu usuario está perdiendo tiempo. La experiencia del usuario no debería verse afectada debido a los requisitos del negocio. Entonces, ¿cómo lo estamos haciendo hasta ahora? ¿Es rápido? Bueno, no. Pero, ¿es confiable? Tampoco. Imagina que mientras estás agregando un usuario a una lista de correo, un servicio se cae. Necesitas gestionar los reintentos. Uno, dos, tres, cuatro reintentos. ¿Y si algo falla permanentemente? Necesitas registrar estos errores en un servicio de registro. Y también necesitas idear un sistema de recuperación. Por lo tanto, la estimación para construir esta característica muy simple ahora es de semanas en lugar de días. Necesitas configurar la infraestructura y los procesos.
5. Solving Partial Failures with Ingest
Las fallas parciales son malas. Ignorar errores, mostrar errores a los usuarios o hacer que los usuarios vuelvan a intentar registrarse puede llevar a la pérdida de clientes y entradas duplicadas. Esto resulta en una aplicación lenta y frustrante. Para resolver esto, podemos mover tareas no bloqueantes a trabajos en segundo plano utilizando Ingest. Ingest es una capa de confiabilidad que te permite definir y ejecutar funciones de forma asíncrona. Proporciona un panel de control para monitorear y administrar trabajos.
Además, las fallas parciales son realmente malas. Entonces, imagina esto. Has agregado al usuario a la database, pero no le has enviado un correo electrónico. Ahora tenemos tres opciones. Primero, puedes ignorar el error, lo que significa que el usuario no está en la lista de correo. Segundo, aún peor, mostramos al usuario el error, lo que llevará a la pérdida de un cliente. Y tercero, el peor caso de todos, el usuario volverá a intentar registrarse. Veamos eso. Así que supongamos que el usuario recibe el error e intenta registrarse nuevamente. Pero ahora, el usuario que se crea generará un error porque hay un duplicado. Bueno, buena suerte recuperándote de eso. Así que este es el lío en el que estamos. Y la aplicación tarda una eternidad en funcionar. Me lleva una eternidad construirla. Estaré molesto en mi trabajo porque de repente tengo que lidiar con la acumulación de soporte. Aún no estamos lidiando con las fallas persistentes. Y todos están descontentos. Mi jefe está descontento. Estoy estresado. No puedo dormir. Pero hay una solución. Podemos hacer que nuestro code sea más rápido y confiable. Entonces, movamos las tareas no bloqueantes a trabajos en segundo plano. Primero, agregaremos Ingest al proyecto. Ingest es una capa de confiabilidad para tu aplicación. Entonces, con Ingest, defines funciones o flujos de trabajo utilizando su SDK directamente en tu base de code, y luego los sirves a través de un punto de conexión HTTP en tu aplicación. Entonces, Ingest se encarga de ejecutar funciones de forma confiable de manera asíncrona. También hay un panel de control donde puedes monitorear,
6. Using Ingest for Reliable Function Execution
Agregamos una capa de confiabilidad llamada Ingest. Las funciones se envuelven en Ingest.create para ejecutarse cuando se activa un evento. Se utiliza el mismo nombre de evento para varias funciones que se ejecutan simultáneamente, conocido como fan out. En lugar de invocar las funciones directamente, desencadenamos eventos en Ingest a través de un punto de conexión HTTP. Ingest ejecuta las funciones y proporciona notificaciones en el panel de control. Ingest vuelve a intentar automáticamente las funciones fallidas hasta que tengan éxito.
debug, y administra tus trabajos. Todo es visual. Entonces, así es como se ve tu aplicación ahora. Vamos a agregar una capa de confiabilidad que es Ingest. Primero, vamos a envolver esta función en la función Ingest.create. Como puedes ver, estamos proporcionando un nombre de evento. Más tarde, cuando el usuario se registre, desencadenaremos un evento con este nombre. Lo verás en un segundo. Esto le dirá a Ingest que ejecute la función. Así es como se vería en
code. Estamos creando la función. Proporcionamos el nombre del evento e invocamos nuestro código existente de MailChimp
code de antes. Y ahora haremos lo mismo para la otra función. Como puedes ver, estamos usando el mismo nombre de evento. Esto se debe a que queremos que estas dos funciones se ejecuten al mismo tiempo. Entonces, cuando el usuario se registre, queremos que estas dos funciones se ejecuten. Este patrón se llama comúnmente fan out. Entonces, ahora cuando el usuario haga clic en el botón, enviaremos un evento a Ingest. Así es como se ve en el
code. En lugar de invocar estas funciones directamente, desencadenaremos un evento en Ingest. Como mencioné antes, exponemos funciones a Ingest a través de un punto de conexión HTTP. Ingest utiliza este punto de conexión para ejecutar las funciones específicas cuando se activa un evento. Este es el punto de conexión. Ingest lo utilizará para descargar las definiciones de las funciones y luego ejecutarlas. Y aquí está el flujo completo. Entonces, Ingest llama a las funciones correctas en el momento preciso que deseas. Y luego en el panel de control, recibirás una notificación de que se ha desencadenado un evento, que a su vez llamó a dos funciones. Así que vemos que se completaron y cuándo. Todo esto se ve bien. Pero, ¿qué sucede cuando hay un fallo? Bueno, veamos eso. Ingest invoca la función y digamos que falla con un error
code. Entonces, lo volverá a intentar una y otra vez hasta que finalmente tenga éxito. No necesitas
7. Explorando Funcionalidades Adicionales de Ingest
Puedes solucionar fácilmente errores con la herramienta de consola de Ingest y recuperarte volviendo a activar eventos fallidos. Ingest permite programar tareas en el futuro y orquestar procesos de múltiples pasos. Aumenta la retención de usuarios enviando campañas de correo electrónico de activación.
preocuparte por eso. Además, obtendrás un registro detallado de lo que sucedió. Sé que es difícil de creer, pero a veces los errores persisten no debido a la falta de servicio, sino porque hay errores en nuestro
code. Sé que es difícil de creer. Pero en esos casos, en realidad puedes depurar fácilmente con la herramienta de consola de Ingest y una vez que hayas corregido tu función, puedes recuperarte volviendo a activar eventos fallidos. Entonces, ¿cómo lo estamos haciendo ahora? Queríamos hacer que nuestra aplicación sea más rápida, así que movimos las tareas no bloqueantes del camino crítico del usuario a trabajos en segundo plano. Pero además, obtuvimos confiabilidad como una buena adición. Así que ahora tenemos acceso a esta gran infraestructura. Entonces, veamos qué más podemos hacer con ella. Así es como se ve nuestra aplicación en este momento. Aún no te lo había dicho, pero Ingest en realidad te permite programar tareas en el futuro y también orquestar procesos de múltiples pasos. Así que veamos la función de enviar correo electrónico. Aquí, simplemente estamos enviando un correo de bienvenida pero siempre es bueno aumentar la retención de usuarios. Podríamos enviarles una campaña de correo electrónico de activación durante la primera semana. ¿Cómo lo haríamos? Así que primero creemos una función de Ingest,
8. Building a Drip Campaign with Ingest
Podemos usar los pasos de Ingest para construir una campaña de goteo con progresión secuencial. Ingest se encarga de la programación para pausar la ejecución de la función. El último paso es el correo electrónico final con consejos. La campaña puede ser dinámica según las acciones del usuario. Usaremos el evento de reserva para determinar el curso de acción.
que reaccionará al mismo evento. Hasta ahora, hemos estado hablando del patrón de propagación, donde tienes múltiples funciones que se activan en el mismo evento. Sin embargo, muchas tareas requieren una progresión secuencial. Aquí estamos construyendo una campaña de goteo, por lo que es conveniente que podamos expresar toda la línea de tiempo como un
code procedural. Entonces, usaremos los pasos de Ingest dentro de esta función. Estamos aquí, como puedes ver, estamos usando un paso de Ingest que se ejecuta. De esta manera, el
code se volverá a intentar automáticamente si falla. Pero el
code que se ejecuta correctamente nunca se volverá a intentar. Lo veremos en acción en un momento. Y primero, estamos enviando un correo electrónico de bienvenida. Esta es la misma parte, la misma parte que hicimos antes. Luego, Ingest pausará la ejecución de esta función durante cuatro días. Para esto, estamos usando step.sleep. Desde la perspectiva de un programador, se ve similar a poner un tiempo de espera, pero en realidad, en segundo plano, Ingest se encarga de la programación por ti. Entonces, esto significa que tu función
serverless no se ejecuta durante cuatro días. Entonces, no tienes que vender tu riñón para pagar tu factura de
AWS. Y el último paso es el correo electrónico final con
tips. Si hay un fallo en uno de los pasos, Ingest sabrá que los otros pasos funcionaron y solo volverá a intentar ese paso hasta que funcione. Entonces, ahora hemos construido una exitosa campaña de goteo y nos merecemos un aplauso. Pero en realidad podemos hacerlo mejor. Imagina que alguien ya se ha registrado e inmediatamente ha realizado una reserva. No tendría sentido que recibieran el mismo correo electrónico que alguien que no finalizó una reserva. Tal vez necesiten diferentes tipos de
tips o diferentes llamadas a la acción. La campaña podría ser realmente dinámica según las acciones del usuario. Entonces, hagámoslo. Eliminemos los dos últimos pasos. En otro lugar de tu aplicación, cuando el usuario completa una reserva, se envía un evento llamado booking.created, al igual que user.signup. Entonces, ahora usamos este evento para determinar el curso de acción. Aquí, esperamos cuatro días para ver si este evento incluso sucederá. A continuación, usaremos un evento de reserva para determinar el curso de acción. Si se realizó la reserva, recompensaremos
9. Expanding the Scope of Ingest
Si se realizó la reserva, recompensaremos a esta persona con consejos para usuarios avanzados. Hay numerosos casos de uso que van más allá de las campañas de marketing. Puedes construir flujos de pago complejos, LLM, encadenamiento de comandos o transformación de datos en múltiples pasos. Ingest también es independiente del framework y del lenguaje.
Recompensaremos a esta persona con consejos para usuarios avanzados. Y, bueno, si necesitan cuatro días para hacer una reserva, necesitarán algunos consejos básicos. Y esto es realmente divertido, por eso me detuve ahí. Podrías volverte loco y crear muchos correos electrónicos con muchos consejos. Y hablando de consejos, todo esto es solo la punta del iceberg. Aquí estamos hablando de enviar correos electrónicos. Pero Ingest no es solo una herramienta para enviar correos electrónicos. Hay numerosos casos de uso que van más allá de las campañas de marketing. Puedes construir flujos de pago complejos, LLM, encadenamiento de comandos o transformación de datos en múltiples pasos. Siempre que necesites que ocurran muchas cosas en respuesta a un evento dado, puedes considerar Ingest. Por ejemplo, SoundCloud utiliza Ingest para agilizar la generación de videos dinámicos. Y luego, AOMNI ha utilizado Ingest para construir ventas impulsadas por IA utilizando LLM sin servidor. Resend, la plataforma de envío de correos electrónicos que en realidad utilizamos en el ejemplo anterior, utiliza Ingest para verificar los dominios de correo electrónico con flujos de trabajo sin servidor. Simplemente funciona en cualquier nube, Vercel, Netlify, tú lo nombras. Además, también puedes integrar, puedes migrar de una nube a otra sin tiempo de inactividad. Aquí tienes una publicación de blog,
10. Expanding SDKs and Importance of Reliability
Recientemente agregamos soporte para BAN y ASTRA. Nuestros SDK están disponibles para TypeScript, Python y Go, con planes de agregar más. Combina y combina los SDK en tus flujos de trabajo e invoca funciones escritas en un lenguaje desde otro. También tenemos un servidor de desarrollo local para facilitar las pruebas. Construir sistemas confiables es crucial para la satisfacción del usuario y la productividad del equipo. Ingest sirve como una capa de confiabilidad, pero tarde o temprano necesitarás una solución. La confiabilidad debe considerarse desde el principio en las elecciones arquitectónicas. Gracias.
si tienes curiosidad. Ingest también es agnóstico de
framework. Aquí hay solo algunos de ellos. Pero también hemos agregado recientemente soporte para BAN y ASTRA, por ejemplo. Y finalmente, también es agnóstico de lenguaje. En este ejemplo, vimos mucho
TypeScript y
type safety. Pero además de
TypeScript, también tenemos SDK para Python y Go. También estamos buscando agregar más. Y por cierto, nuestra especificación de SDK es de código abierto y estamos invitando contribuciones. Y dato curioso, también puedes combinar y combinar todos esos SDK en tus flujos de trabajo e invocar funciones escritas en un lenguaje en otro. También hay, finalmente, un servidor de desarrollo local, que no requiere que inicies sesión, por lo que puedes verlo ahora mismo. Pero, sabes, aquí hablé mucho sobre Ingest. Pero esta charla no se trata solo de Ingest. Al construir aplicaciones de producción del mundo real, la confiabilidad es realmente importante. No solo mantiene a tus usuarios felices, sino que también hace que tu equipo sea más productivo. Y tú como desarrollador te ves menos obstaculizado por el mantenimiento y las operaciones. Lograr la confiabilidad es difícil. Cada ingeniero que alguna vez ha tenido que construir un sistema confiable a gran escala conoce la cantidad de iteración e infraestructura que implica. En este ejemplo, usamos Ingest como la capa de confiabilidad. Pero ya sea que uses soluciones de terceros o no, tarde o temprano terminarás necesitando una. La confiabilidad es como la
security. Es difícil agregarla después. Entonces, incorporarla en tus elecciones arquitectónicas desde el principio generalmente es una buena idea. Y sí, gracias a todos. Si quieres comunicarte conmigo o ser amigos, aquí es donde puedes encontrarme. Gracias.
Comments