El desarrollo de aplicaciones basado en conceptos como microservicios y las llamadas funciones sin servidor está emergiendo como la nueva norma para la entrega de software empresarial. Es una progresión lógica; ahora vivimos en un mundo nativo de la nube, y estos modelos de desarrollo modernos son un ajuste natural para entornos distribuidos basados ​​en la nube. Pero simplemente crear e implementar servicios y funciones no es suficiente.

Por sí solo, un solo microservicio no logra mucho. También necesitará una forma de conectar esos componentes, es decir, conectarlos para que puedan intercambiar datos, formando una verdadera aplicación. De hecho, es una de las decisiones arquitectónicas más importantes que se deben tomar.

Se han desarrollado varios mecanismos para hacer esto a lo largo de los años, que van desde colas de mensajes hasta buses de servicios empresariales (ESB), Java Message Service (JMS), API RESTful y otros métodos de conexión personalizados. Las ofertas más recientes, sobre todo Apache Kafka, se han diseñado en torno al concepto de transmisión de datos.

El interés en esta última categoría está creciendo, en parte porque la transmisión de datos se considera una herramienta útil para implementar la arquitectura impulsada por eventos, un patrón de diseño de software en el que los datos de la aplicación se modelan como flujos de eventos, en lugar de operaciones en registros estáticos. Examinemos cómo funciona este modelo y luego exploremos por qué Kafka, en particular, a menudo se considera la plataforma predeterminada para administrar datos en aplicaciones impulsadas por eventos.

¿Qué es un evento, de todos modos?

Incluso si el modelo de software basado en eventos es nuevo para usted, el concepto básico de eventos debería resultarle familiar. En pocas palabras, los eventos son cosas que suceden dentro de un sistema de software o, en términos más generales, durante la operación de una empresa u otro proceso humano. Una aplicación impulsada por eventos es aquella que se organiza en torno a reaccionar ante estos eventos. Los ejemplos de eventos pueden incluir:

• Un nuevo cliente solicita un inicio de sesión de cuenta en línea
• Un almacén de piezas actualiza su recuento de inventario
• Una transacción de pago completada
• Se denegó un intento de acceso no autorizado
• Un envío llegó a su destino.

Es probable que cada uno de estos eventos desencadene una o más acciones o procesos en respuesta. Un ejemplo podría ser simplemente registrar el evento con fines de monitoreo. Otros, según la lista de eventos anterior, pueden incluir:

• El cliente recibe un correo electrónico de confirmación de que se creó la nueva cuenta.
• El software de gestión de la cadena de suministro realiza pedidos de materiales que se están agotando
• El centro logístico está dirigido a armar un pedido para su entrega.
• La cuenta está bloqueada y se notifica al personal de seguridad
• El ticket de venta está cerrado

Como puede ver, el concepto de eventos en los sistemas de software se alinea estrechamente con la forma en que la mayoría de nosotros pensamos sobre nuestra vida cotidiana. No existe una regla estricta sobre lo que constituye un evento o cuán granulares deberían ser los eventos en un sistema de software dado (de hecho, decidir estas cosas a menudo requiere mucha reflexión). Además, la forma en que se manejan los eventos dependerá del tipo específico de arquitectura que cree.

Sin embargo, los beneficios de pensar en el diseño de aplicaciones de esta manera son convincentes. Por un lado, la organización en torno a eventos facilita el desarrollo de la lógica empresarial que modela con precisión los procesos del mundo real. También puede facilitar la inserción de nuevos procesos en el flujo de trabajo en una fecha posterior; por ejemplo, si una nueva regulación gubernamental requiere un paso adicional en el proceso para garantizar el cumplimiento, el servicio que maneja esa acción puede ser desencadenado por un evento existente, en lugar de reescribir la lógica de la aplicación en múltiples componentes estrechamente acoplados para acomodar el nuevo proceso comercial . Y organizarse en torno a eventos puede ayudar a reducir la cantidad de conexiones uno a uno dentro de un sistema distribuido y mejorar la reutilización del código, aumentando el valor de los microservicios que crea.

Patrones de arquitectura impulsada por eventos

Cuando llega el momento de implementar una arquitectura impulsada por eventos, naturalmente hay más de una forma de hacerlo. Algunos patrones pueden ser más fáciles de implementar, mientras que otros pueden adaptarse mejor a necesidades complejas. Cuál es el mejor para un caso de uso determinado dependerá de una serie de factores, incluidos cuántos microservicios están en juego, qué tan estrechamente deben estar acoplados y cuánta «charla de datos» puede admitir el sistema. Ejemplos de patrones populares impulsados por eventos incluyen:

Notificación de eventos

En este modelo, un microservicio envía eventos simplemente para notificar a otros sistemas de un cambio en su dominio. Por ejemplo, un servicio de cuenta de usuario puede enviar un evento de notificación cuando se crea un nuevo inicio de sesión. Lo que otros sistemas elijan hacer con esa información depende en gran medida de ellos; el servicio que emitió la notificación simplemente continúa con su actividad. Los eventos de notificación generalmente no llevan muchos datos consigo, lo que da como resultado un sistema poco acoplado con un tráfico de red mínimo gastado en mensajería.

Transferencia de estado transmitida por eventos

Un paso más allá de la simple notificación, en este modelo, el destinatario de un evento también recibe los datos que necesita para realizar un trabajo adicional. El servicio de cuenta de usuario mencionado anteriormente, por ejemplo, podría emitir un evento que incluye un paquete de datos que contiene el ID de inicio de sesión del nuevo usuario, el nombre completo, la contraseña hash y otros detalles pertinentes. Este modelo puede resultar atractivo para los desarrolladores familiarizados con las interfaces RESTful, pero dependiendo de la complejidad del sistema, puede generar mucho tráfico de datos en la red y duplicación de datos en el almacenamiento.

Abastecimiento de eventos

El objetivo de este modelo es representar cada cambio de estado en un sistema como un evento, cada uno registrado en orden cronológico. Al hacerlo, el flujo de eventos en sí mismo se convierte en la principal fuente de verdad para el sistema. Por ejemplo, debería ser posible «reproducir» una secuencia de eventos para recrear el estado de una base de datos SQL en un momento dado. Este modelo presenta muchas posibilidades interesantes, pero puede ser un desafío hacerlo bien, especialmente cuando los eventos requieren la participación de sistemas externos.

Esta lista no es exhaustiva y, con el tiempo, pueden surgir aún más patrones impulsados ​​por eventos. Para una inmersión más profunda, consulte este artículo de Martin Fowler, uno de los expertos más destacados en arquitectura moderna.

El caso de Kafka

Como se mencionó anteriormente, a lo largo de los años se han adoptado varios métodos para conectar los servicios, siendo Apache Kafka uno de los más nuevos y populares. Dicho esto, las colas de mensajes tradicionales como RabbitMQ todavía tienen muchos casos de uso, incluso en modelos impulsados ​​por eventos más débilmente acoplados, como la notificación de eventos, que no necesariamente requieren una plataforma de datos con todas las funciones.

Pero una de las razones por las que Kafka es tan popular en este momento es porque tiene muchas cosas buenas a su favor, incluido su pedigrí:

• Fue creado en LinkedIn, donde uno de los requisitos de diseño era que pudiera sostener operaciones a gran escala.
• Es un proyecto de código abierto mantenido por la Fundación Apache.
• Confluent, una empresa fundada por algunos de los desarrolladores originales de Kafka, ofrece una plataforma de nivel empresarial basada en Kafka.

Además, Kafka tiene características que lo distinguen de las colas de mensajes empresariales tradicionales y los buses de servicio:

• Kafka es una plataforma distribuida, lo que significa que los datos se pueden replicar en un clúster de servidores para tolerancia a fallas, incluida la compatibilidad con la ubicación geográfica.
• En comparación con los modelos tradicionales de cola y publicación-suscripción, Kafka ofrece un modelo híbrido que combina las ventajas de ambos: el procesamiento de mensajes sigue siendo escalable incluso cuando los mensajes son recibidos por varios consumidores.
• Ofrece sólidas garantías de que los mensajes se recibirán en el orden cronológico en el que se publicaron.
• El sistema de almacenamiento de Kafka puede escalar de manera eficiente a terabytes de datos, con un período de retención configurable, lo que significa que incluso cuando ocurren interrupciones que duran días enteros, una vez que se restablece el servicio, el flujo de eventos continúa en orden.
• La retención configurable también significa que Kafka es igualmente adecuado para aplicaciones de transmisión en tiempo real y canalizaciones de datos por lotes periódicos.
• Además, Kafka ofrece una API de procesamiento de flujo que permite transformaciones complejas de datos a medida que pasan entre los puntos finales del servicio.

Estas y otras características hacen de Kafka una opción atractiva para patrones impulsados por eventos más avanzados, como el abastecimiento de eventos, donde las colas de mensajes no son una buena opción. El sitio web de Apache Kafka tiene mucha más información sobre casos de uso, API, seguridad y otros detalles de implementación, pero también hay una cantidad creciente de información en línea sobre conceptos y mejores prácticas.

Obtenga más información sobre Kafka y la arquitectura impulsada por eventos

Un lugar para comenzar es este curso intensivo de podcasts de 15 minutos con Neha Narkhede, cofundadora y directora de tecnología de Confluent y co-creadora de Kafka, en el que analiza la creciente importancia de la transmisión de datos y la arquitectura impulsada por eventos. Otros excelentes recursos incluyen:

• Poniendo Apache Kafka en uso: una guía práctica para construir una plataforma de transmisión de eventos, por Jay Kreps de Confluent (Parte 1 y Parte 2)
• Cómo ofrecer una arquitectura basada en eventos, una inmersión en los detalles arquitectónicos de Richard Seroter de Pivotal
• Apache Kafka Streaming Platform Explained, un video de la charla de Neha Narkhede de la conferencia SpringOne Platform 2018
• Spring Boot y Kafka: la nueva plataforma empresarial, un video del discurso de apertura de James Watters de Pivotal en Kafka Summit 2019

Empezando

La arquitectura basada en eventos está ganando popularidad, y con razón. Desde una perspectiva técnica, proporciona un método eficaz para conectar microservicios que pueden ayudar a los sistemas a prueba de futuro; por ejemplo, está creciendo el interés en las funciones sin servidor, como AWS Lambda, Azure Functions o Knative, y éstas se basan inherentemente en eventos. Además, cuando se combinan con herramientas modernas de transmisión de datos como Apache Kafka, las arquitecturas basadas en eventos se vuelven más versátiles, resistentes y confiables que con los métodos de mensajería anteriores.

Pero quizás la “característica” más importante del patrón impulsado por eventos es que modela cómo operan las empresas en el mundo real. Las organizaciones que quieran explorar la creación de aplicaciones de esta manera deben, en primer lugar, trazar un mapa de los eventos que deben modelarse en sus flujos de trabajo. Esta fase de planificación generalmente requiere la colaboración directa entre los gerentes de línea de negocio y los grupos de desarrollo de aplicaciones.

Y esa puede ser la verdadera «salsa secreta» de la arquitectura impulsada por eventos: no solo es poderosa, sino que también ayuda a fomentar una verdadera alineación entre los objetivos comerciales y TI.