Blog de Amazon Web Services (AWS)
Creación de consumidores ad hoc para arquitecturas basadas en eventos
Por Corneliu Croitoru, arquitecto de Media Streaming y Edge y Benjamin Smith, principal desarrollador de Serverless.
En enero de 2022, el equipo de Serverless Developer Advocate lanzó Serverlesspresso Extensions, un programa que te permite contribuir a Serverlesspresso. Se trata de una aplicación multiusuario basada en eventos para una cafetería emergente que te permite hacer pedidos desde tu teléfono. En 2022, Serverlesspresso procesó más de 20000 pedidos en eventos tecnológicos en todo el mundo. El objetivo de las extensiones Serverlesspresso es mostrar el poder y la simplicidad de la evolución de una aplicación basada en eventos.
La arquitectura basada en eventos es un patrón de diseño que permite a los desarrolladores crear y desarrollar aplicaciones respondiendo a los eventos generados por diversas partes del sistema. Para las aplicaciones modernas, la necesidad de enfoques flexibles y escalables es fundamental, y la arquitectura basada en eventos puede proporcionar una solución eficaz.
Esta entrada de blog muestra cómo crear e implementar una extensión para una aplicación basada en eventos. Describe las ventajas y los desafíos de la evolución de las aplicaciones impulsadas por eventos. También presenta un ejemplo real que se creó en menos de 24 horas.
Integraciones desacopladas
Una ventaja clave de la arquitectura basada en eventos es su capacidad para desacoplar diferentes partes del sistema, lo que facilita la gestión de los cambios y la evolución de la aplicación. En las aplicaciones monolíticas tradicionales, los cambios en una parte del sistema pueden afectar a toda la aplicación.
Con una arquitectura basada en eventos, puede cambiar partes individuales del sistema sin afectar al resto de la aplicación. La arquitectura basada en eventos también facilita la integración de nuevas funciones en una aplicación existente al crear nuevos controladores de eventos para responder a los eventos existentes. De esta forma, puede añadir nuevas funciones sin afectar al sistema existente, lo que facilita las pruebas y la implementación.
Los siguientes diagramas ilustran cómo añadir y eliminar consumidores y productores sin afectar a la aplicación principal.
Añadir y eliminar extensiones impulsadas por eventos
La extensión 2 consume los eventos del bus de eventos y los devuelve al bus. Se puede añadir a la aplicación principal sin crear dependencias. Cuando se elimina la extensión 2, la aplicación principal permanece sin cambios.
En las aplicaciones monolíticas, las funciones adicionales pueden crear dependencias con respecto a la aplicación principal. La eliminación de esas funciones mantiene esas dependencias en su lugar, lo que hace que sea más complejo eliminarlas.
Añadir y quitar extensiones monolíticas
Colaboración
En una aplicación monolítica tradicional, puede resultar difícil colaborar con varios desarrolladores en una única base de código. Puede provocar conflictos, errores y otros problemas que deben resolverse. Integrar nuevas funciones y componentes en estas aplicaciones puede resultar difícil, especialmente cuando varios desarrolladores utilizan tecnologías diferentes. La implementación de actualizaciones también puede resultar compleja cuando participan varios desarrolladores y es necesario actualizar diferentes partes de la aplicación simultáneamente.
En el caso de las aplicaciones basadas en eventos, estos desafíos suelen ser menos importantes. Un consumidor bien diseñado tiene límites de permisos bien definidos. Sus recursos no deberían necesitar permiso para interactuar con recursos que no estén incluidos en la definición de extensión. Esto significa que puede desplegarlos y eliminarlos independientemente de otras extensiones y de la aplicación principal. Esto facilita la colaboración con varios desarrolladores en diferentes lenguajes, tiempos de ejecución y marcos de implementación.
Comentarios prácticamente en tiempo real
Otra característica de la arquitectura basada en eventos es la capacidad de proporcionar comentarios en tiempo real a los usuarios. Esto se debe a que los consumidores pueden procesar los eventos a medida que ocurren, lo que permite proporcionar comentarios inmediatos. Esto puede resultar útil en aplicaciones que gestionan grandes volúmenes de datos o que interactúan con varios usuarios, ya que pueden proporcionar actualizaciones en tiempo real y garantizar que la aplicación siga respondiendo.
Un enfoque alternativo para la retroalimentación casi en tiempo real es utilizar el procesamiento por lotes. Esto implica agrupar varios eventos o puntos de datos en un lote y procesarlos. La elección entre procesar los datos por lotes o en tiempo real con eventos depende de la cantidad de datos que se procesen, de los requerimientos de latencia y de la complejidad de la lógica de procesamiento. El procesamiento por lotes puede ser más eficiente para grandes volúmenes de datos, ya que reduce la sobrecarga que supone procesar cada evento de forma individual, mientras que el procesamiento de datos con eventos puede ser más adecuado para aplicaciones en tiempo real que requieren baja latencia.
La extensión Serverlesspresso más reciente utiliza un enfoque basado en eventos para obtener información sobre la aplicación en tiempo real.
La extensión del tiempo de espera promedio
Corneliu Croitoru creó una nueva extensión que calcula la espera media para cada bebida en la cafetería Serverlesspresso. Esta extensión utiliza AWS Step Functions, DynamoDB y AWS Lambda. La aplicación muestra los resultados prácticamente en tiempo real, lo que permite a los clientes ver cuánto tiempo pueden tener que esperar para recibir su pedido. La extensión utiliza el kit de desarrollo en la nube (CDK) de AWS para la implementación.
La extensión utiliza el bus de eventos de Amazon EventBridge existente para iniciar un flujo de trabajo de Step Functions. El flujo de trabajo se activa a partir de los eventos de envío y finalización del pedido y calcula el tiempo medio de espera para cada tipo de bebida (por ejemplo, Caffe Latte). A continuación, esta información se envía de vuelta al bus de eventos de Serverlesspresso.
El siguiente diagrama ilustra el flujo de trabajo de Step Functions:
Cuando se emite un nuevo evento de envío de pedidos, el flujo de trabajo de Step Functions conserva la marca de tiempo del evento en una tabla de DynamoDB, un almacén de datos de clave/valor. Utiliza el identificador de pedido único como clave. Cuando se emite un evento de finalización de un pedido, el flujo de trabajo conserva la marca de tiempo de finalización en DynamoDB. A continuación, el flujo de trabajo invoca una función de Lambda para calcular la duración media de esa bebida específica utilizando los últimos 10 pedidos almacenados en la tabla de DynamoDB.
Esta es la estructura de la tabla de DynamoDB:
El flujo de trabajo envía un evento al bus de eventos de Serverlesspresso con la duración calculada y el tipo de bebida. Una regla en el bus de eventos dirige este evento a un tema de IoT, que lo publica en la aplicación front-end a través de una conexión WebSocket abierta existente. El resultado aparece en la interfaz:
Enfoques alternativos
Existen varios enfoques alternativos que puedes usar para crear una extensión de «espera promedio» en tiempo real sin usar eventos.
Uno de estos enfoques podría consistir en utilizar DynamoDB como caché para los datos basados en eventos. De esta forma, sería posible consultar la base de datos periódicamente para comprobar si hay actualizaciones. Este enfoque se puede implementar agregando un campo de fecha y hora a los registros de la base de datos y consultando los registros que se hayan actualizado desde la última vez que se realizó la comprobación.
Como alternativa, puede utilizar las transmisiones de DynamoDB para capturar los cambios a medida que se producen, en lugar de suscribirse directamente a los nuevos eventos. Sin embargo, estos enfoques pueden enfrentarse a varios desafíos. La extensión requeriría permiso para leer los datos de la tabla o transmisión de DynamoDB. Dado que el recurso de tabla de DynamoDB se define en la plantilla principal de la aplicación, esto plantea problemas de propiedad, límites de permisos y dependencias. Añade complejidad adicional a la aplicación, ya que la extensión no estaría desacoplada del núcleo.
Los desafíos
El mayor desafío a la hora de crear esta extensión es el cambio necesario en la mentalidad de los desarrolladores. A pesar de comprender los principios de la arquitectura disociada basada en eventos, el concepto no quedó claro hasta que se creó una extensión de la arquitectura basada en eventos.
Por ejemplo, puede pensar que es necesario implementar la aplicación existente para enviar pedidos, emitir eventos en el bus de eventos de la aplicación e interactuar con varios recursos principales. El equipo de desarrollo discutió el grado en que la extensión debería interactuar con los componentes de la aplicación existentes. No se trataba de una mentalidad impulsada por los acontecimientos.
Cada nueva extensión debe basarse completamente en eventos. Esto significa que solo puede interactuar con la aplicación principal a través del bus de eventos compartido mediante el consumo y la emisión de eventos. También significa que puede escribir la extensión en cualquier entorno de ejecución, con cualquier marco de infraestructura como código (IaC), y que debería ser posible implementar y destruir la pila de extensiones sin afectar a la aplicación principal.
Una vez que comprenda esto, el siguiente desafío será la capacidad de detección. Encontrar los eventos adecuados para consumirlos puede resultar más difícil de lo esperado. Por eso es importante documentar los eventos a medida que se crea la aplicación. El esquema del evento, el productor y el consumidor deben estar documentados y evolucionar con cada versión del evento. El catálogo de eventos de Serverlesspresso ayuda a superar esta situación en este ejemplo.
Por último, el reproductor de eventos puede emitir eventos realistas de Serverlesspresso en el bus de eventos. Esto reemplaza la necesidad de implementar la pila principal de aplicaciones.
Conclusión
El programa Serverlesspresso Extensions muestra la simplicidad de desarrollar aplicaciones basadas en eventos. La creación de arquitecturas basadas en eventos permite realizar integraciones desacopladas, lo que facilita la gestión de los cambios y el desarrollo de la aplicación. También simplifica la colaboración entre varios equipos, ya que los usuarios de los eventos pueden ir y venir de forma independiente sin que ello afecte al procedimiento ni a la aplicación principal.
Con estos principios, la extensión del tiempo de espera promedio se creó e implementó en 24 horas, utilizando un marco de IaC diferente al de la aplicación principal.
Usa el repositorio de GitHub de extensiones Serverlesspresso para leer cómo crear más extensiones Serverlesspresso.
Para obtener más recursos de aprendizaje sin servidor, visita Serverless Land.
Este contenido es una traducción del Blog Original en inglés traducido por Christian Bolaños y revisado por Diego Casas.