Construir microservicios basados en eventos

Capítulo 1. Por qué microservicios basados en eventos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

El medio es el mensaje.

Marshall McLuhan

McLuhan sostiene que no es el contenido de los medios de comunicación, sino el compromiso con su medio, lo que repercute en la humanidad e introduce cambios fundamentales en la sociedad. Los periódicos, la radio, la televisión, Internet, la mensajería instantánea y los medios sociales han cambiado la interacción humana y las estructuras sociales gracias a nuestrocompromiso colectivo.

Lo mismo ocurre con las arquitecturas de los sistemas informáticos. Basta con echar un vistazo a la historia de los inventos informáticos para ver cómo las comunicaciones en red, las bases de datos relacionales, los desarrollos de big data y la computación en nube han alterado significativamente la forma en que se construyen las arquitecturas y se realiza el trabajo. Cada uno de estos inventos cambió no sólo la forma en que se utilizaba la tecnología en los distintos proyectos de software, sino también la forma en que las organizaciones, los equipos y las personas se comunicaban entre sí. Desde los mainframes centralizados hasta las aplicaciones móviles distribuidas, cada nuevo medio ha cambiado fundamentalmente la relación de las personas con la informática.

El medio del evento producido y consumido asíncronamente ha cambiado radicalmente gracias a la tecnología moderna. Ahora estos eventos pueden persistir indefinidamente, a escala extremadamente grande, y ser consumidos por cualquier servicio tantas veces como sea necesario. Los recursos informáticos pueden adquirirse y liberarse fácilmente bajo demanda, lo que facilita la creación y gestión de microservicios. Los microservicios pueden almacenar y gestionar sus datos según sus propias necesidades, y hacerlo a una escala que antes estaba limitada a las soluciones de big data basadas en lotes. Estas mejoras del humilde y sencillo medio basado en eventos tienen repercusiones de gran alcance que no sólo cambian las arquitecturas informáticas, sino que también remodelan por completo la forma en que los equipos, las personas y las organizaciones crean sistemas y empresas.

¿Qué son los microservicios dirigidos por eventos?

Los microservicios y las arquitecturas de estilo microservicio existen desde hace muchos años, en muchas formas diferentes y con muchos nombres distintos. Las arquitecturas orientadas a servicios (SOA) suelen estar compuestas por múltiples microservicios que se comunican directamente entre sí de forma síncrona. Las arquitecturas de paso de mensajes utilizan eventos consumibles para comunicarse entre sí de forma asíncrona. La comunicación basada en eventos no es ciertamente nueva, pero la necesidad de manejar grandes conjuntos de datos, a escala y en tiempo real, es nueva y requiere un cambio de los antiguos estilos arquitectónicos.

En una arquitectura moderna de microservicios basada en eventos, los sistemas se comunican emitiendo y consumiendo eventos. Estos eventos no se destruyen cuando se consumen, como en los sistemas de paso de mensajes, sino que permanecen disponibles para que otros consumidores los lean cuando lo necesiten. Se trata de una distinción importante, ya que permite los patrones realmente potentes que se tratan en este libro.

Los servicios en sí son pequeños y están creados para ayudar a cumplir los objetivos empresariales necesarios de la organización. Una definición típica de "pequeño" es algo que no se tarda más de dos semanas en escribir. Según otra definición, el servicio debería caber (conceptualmente) en la propia cabeza. Estos servicios consumen eventos de flujos de eventos de entrada; aplican su lógica empresarial específica; y pueden emitir sus propios eventos de salida, proporcionar datos para el acceso solicitud-respuesta, comunicarse con una API de terceros o realizar otras acciones necesarias. Como se detallará en este libro, estos servicios pueden ser con o sin estado, complejos o sencillos; y pueden implementarse como aplicaciones independientes de larga duración o ejecutarse como una función utilizando Funciones como Servicio.

Esta combinación de flujos de eventos y microservicios forma un gráfico interconectado de actividad en toda una organización empresarial. Las arquitecturas informáticas tradicionales, compuestas por monolitos y comunicaciones intermonolitos, tienen una estructura gráfica similar. Ambos gráficos se muestran en la Figura 1-1.

Figura 1-1. Estructuras gráficas de microservicios y monolitos

Identificar cómo hacer que esta estructura gráfica funcione eficientemente implica examinar los dos componentes principales: los nodos y las conexiones. Este capítulo examinará cada uno de ellos por separado.

Introducción al Diseño Orientado al Dominio y a los Contextos Delimitados

El diseño orientado al dominio, acuñado por Eric Evans en su libro del mismo título, introduce algunos de los conceptos necesarios para construir microservicios orientados a eventos. Dada la gran cantidad de artículos, libros y blogs del mes disponibles para hablar de este tema, seré breve en esta sección.

Los siguientes conceptos sustentan el diseño orientado al dominio:

Dominio

El espacio problemático que ocupa una empresa y al que aporta soluciones. Abarca todo aquello con lo que la empresa debe enfrentarse, incluidas las normas, los procesos, las ideas, la terminología específica de la empresa y todo lo relacionado con su espacio problemático, independientemente de que la empresa se ocupe o no de ello. El dominio existe independientemente de la existencia de la empresa.

Subdominio

Un componente del dominio principal. Cada subdominio se centra en un subconjunto específico de responsabilidades y suele reflejar parte de la estructura organizativa de la empresa (como Almacén, Ventas e Ingeniería). Un subdominio puede considerarse un dominio en sí mismo. Los subdominios, como el propio dominio, pertenecen al espacio del problema.

Modelo de dominio (y subdominio)

Una abstracción del dominio real útil para fines empresariales. Las piezas y propiedades del dominio más importantes para la empresa se utilizan para generar el modelo. El modelo de dominio principal de una empresa es discernible a través de los productos que la empresa proporciona a sus clientes, las interfaces mediante las cuales los clientes interactúan con los productos y los diversos procesos y funciones mediante los cuales la empresa cumple sus objetivos declarados. A menudo es necesario perfeccionar los modelos a medida que cambia el dominio y cambian las prioridades empresariales. Un modelo de dominio forma parte del espacio de soluciones, ya que es una construcción que la empresa utiliza para resolver problemas.

Contexto limitado

Los límites lógicos, incluidas las entradas, salidas, eventos, requisitos, procesos y modelos de datos, relevantes para el subdominio. Aunque lo ideal es que un contexto delimitado y un subdominio estén completamente alineados, los sistemas heredados, la deuda técnica y las integraciones de terceros suelen crear excepciones. Los contextos delimitados son también una propiedad del espacio de soluciones y tienen un impacto significativo en la forma en que los microservicios interactúan entre sí.

Los contextos limitados deben estar muy cohesionados. Las operaciones internas del contexto deben ser intensivas y estar estrechamente relacionadas, y la mayor parte de la comunicación debe producirse internamente y no a través de los límites. Tener responsabilidades altamente cohesionadas permite reducir el alcance del diseño y simplificar las implementaciones.

Las conexiones entre contextos delimitados deben estar débilmente acopladas, ya que los cambios realizados dentro de un contexto delimitado deben minimizar o eliminar el impacto en los contextos vecinos. Un acoplamiento laxo puede garantizar que los cambios de requisitos en un contexto no propaguen una oleada de cambios dependientes a los contextos vecinos.

Aprovechar los modelos de dominio y los contextos limitados

Toda organización forma un dominio único entre sí misma y el mundo exterior. Todas las personas que trabajan en la organización lo hacen para satisfacer las necesidades de su dominio.

Este dominio se desglosa en subdominios -quizás, para una empresa centrada en la tecnología, un departamento de Ingeniería, un departamento de Ventas y un departamento de Atención al Cliente-. Cada subdominio tiene sus propios requisitos y obligaciones, y puede subdividirse a su vez. Este proceso de división se repite hasta que los modelos de subdominio son granulares y procesables y pueden ser traducidos en servicios pequeños e independientes por los equipos de implementación. Se establecen contextos delimitados en torno a estos subdominios y constituyen la base para la creación de microservicios.

Alinear los contextos limitados con los requisitos empresariales

Es habitual que los requisitos empresariales de un producto cambien durante su vida útil, quizá debido a cambios organizativos o a nuevas solicitudes de funciones. En cambio, es raro que una empresa necesite cambiar la implementación subyacente de un producto determinado sin que se produzcan cambios en los requisitos empresariales. Por eso los contextos delimitados deben construirse en torno a los requisitos empresariales y no a los tecnológicos.

Alinear los contextos delimitados a los requisitos empresariales permite a los equipos realizar cambios en las implementaciones de microservicios de forma poco acoplada y altamente cohesionada. Proporciona al equipo autonomía para diseñar e implementar una solución para las necesidades empresariales específicas, lo que reduce enormemente las dependencias entre equipos y permite que cada equipo se centre estrictamente en sus propios requisitos.

Por el contrario, alinear los microservicios en función de los requisitos técnicos es problemático. Este patrón se ve a menudo en microservicios síncronos punto a punto mal diseñados y en sistemas informáticos tradicionales de estilo monolítico en los que los equipos poseen capas técnicas específicas de la aplicación. El principal problema de la alineación tecnológica es que distribuye la responsabilidad de cumplir la función empresarial entre varios contextos delimitados, lo que puede implicar a varios equipos con horarios y obligaciones diferentes. Como ningún equipo es el único responsable de implementar una solución, cada servicio se acopla a otro a través de los límites del equipo y de la API, lo que dificulta y encarece los cambios. Un cambio aparentemente inocente, un error o un servicio defectuoso pueden tener graves efectos dominó en las capacidades de servicio al negocio de todos los servicios que utilizan el sistema técnico. La alineación técnica rara vez se utiliza en las arquitecturas de microservicios dirigidas por eventos (EDM) y debe evitarse por completo siempre que sea posible. Eliminar las dependencias tecnológicas y de equipo transversales reducirá la sensibilidad del sistema al cambio.

La Figura 1-2 muestra ambos escenarios: propiedad única a la izquierda y propiedad transversal a la derecha. Con la propiedad única, el equipo está totalmente organizado en torno a los dos requisitos empresariales independientes (contextos delimitados) y tiene un control total sobre su código de aplicación y la capa de base de datos. A la derecha, los equipos se han organizado mediante requisitos técnicos, en los que la capa de aplicación se gestiona por separado de la capa de datos. Esto crea dependencias explícitas entre los equipos, así como dependencias implícitas entre los requisitos empresariales.

Figura 1-2. Alineación en contextos empresariales frente a contextos tecnológicos

Es preferible modelar las arquitecturas de microservicios basadas en eventos en torno a los requisitos empresariales, aunque este enfoque tiene sus desventajas. El código puede replicarse varias veces, y muchos servicios pueden utilizar patrones de acceso a datos similares. Los desarrolladores de productos pueden intentar reducir la repetición compartiendo fuentes de datos con otros productos o acoplándose en los límites. En estos casos, el acoplamiento estrecho posterior puede ser mucho más costoso a largo plazo que repetir la lógica y almacenar datos similares. Estas compensaciones se examinarán con más detalle a lo largo de este libro.

Consejo

Mantén un acoplamiento flexible entre los contextos delimitados y céntrate en minimizar las dependencias entre contextos. Esto permitirá que las implementaciones de contextos delimitados cambien según sea necesario, sin romper posteriormente muchos (o ningún) otros sistemas.

Además, es posible que se exija que cada equipo tenga experiencia en toda la pila, lo que puede complicarse por la necesidad de conjuntos de habilidades especializadas y permisos de acceso. La organización debe hacer operativos los requisitos más comunes, de modo que estos equipos verticales puedan mantenerse a sí mismos, mientras que los conjuntos de habilidades más especializados pueden proporcionarse a través de los equipos, según sea necesario. Estas buenas prácticas se tratan con más detalle en el Capítulo 14.

Estructuras de comunicación

Los equipos, sistemas y personas de una organización deben comunicarse entre sí para cumplir sus objetivos. Estas comunicaciones forman una topología interconectada de dependencias denominada estructura de comunicación. Hay tres estructuras de comunicación principales, y cada una de ellas afecta al modo en que funcionan las empresas.

Estructuras de comunicación empresarial

La estructura de comunicación empresarial(Figura 1-3) dicta la comunicación entre equipos y departamentos, cada uno impulsado por los principales requisitos y responsabilidades que se le asignan. Por ejemplo, Ingeniería produce los productos de software, Ventas vende a los clientes, y Soporte se asegura de que los clientes estén satisfechos. La organización de los equipos y la provisión de sus objetivos, desde las grandes unidades de negocio hasta el trabajo del colaborador individual, entran dentro de esta estructura. Los requisitos empresariales, su asignación a los equipos y las composiciones de los equipos cambian con el tiempo, lo que puede afectar en gran medida a la relación entre la estructura de comunicación empresarial y la estructura de comunicación de implementación.

Figura 1-3. Ejemplo de estructura de comunicación empresarial

Aplicación Estructuras de comunicación

La estructura de comunicación de la implementación(Figura 1-4) son los datos y la lógica pertenecientes al modelo de subdominio, tal y como dicta la organización. Formaliza los procesos empresariales, las estructuras de datos y el diseño del sistema para que las operaciones empresariales puedan realizarse con rapidez y eficacia. Esto da lugar a una compensación en la flexibilidad de la estructura de comunicación empresarial, ya que la redefinición de los requisitos empresariales que debe satisfacer la implementación requiere una reescritura de la lógica. Estas reescrituras suelen ser modificaciones iterativas del modelo de subdominio y del código asociado, que con el tiempo reflejan la evolución de la implementación para satisfacer los nuevos requisitos empresariales.

El ejemplo por excelencia de una estructura de comunicación de implementación para la ingeniería de software es la aplicación de base de datos monolítica. La lógica empresarial de la aplicación se comunica internamente mediante llamadas a funciones o estado compartido. Esta aplicación monolítica, a su vez, se utiliza para satisfacer los requisitos empresariales dictados por la estructura de comunicación empresarial.

Figura 1-4. Ejemplo de estructura de comunicación de la aplicación

Estructuras de comunicación de datos

La estructura de comunicación de datos(Figura 1-5) es el proceso mediante el cual se comunican los datos en toda la empresa y, en particular, entre implementaciones. Aunque a menudo se utiliza una estructura de comunicación de datos que comprende el correo electrónico, la mensajería instantánea y las reuniones para comunicar los cambios empresariales, se ha descuidado en gran medida para las implementaciones de software. Por lo general, su papel se ha desempeñado ad hoc, de sistema a sistema, y la estructura de comunicación de la implantación suele desempeñar una doble función al incluir funciones de comunicación de datos además de sus propios requisitos. Esto ha causado muchos problemas en la forma en que las empresas crecen y cambian con el tiempo, cuyo impacto se evalúa en la siguiente sección.

Figura 1-5. Ejemplo de estructura de comunicación de datos ad hoc

Ley de Conway y estructuras de comunicación

Las organizaciones que diseñan sistemas... se ven obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.

Melvin Conway-¿Cómoinventan los comités? (abril de 1968)

Esta cita, conocida como la ley de Conway, implica que un equipo elaborará productos según las estructuras de comunicación de su organización. Las estructuras de comunicación empresarial organizan a las personas en equipos, y estos equipos suelen elaborar productos delimitados por los límites de su equipo. Las estructuras de comunicación de implementación proporcionan acceso a los modelos de datos de subdominio de un producto determinado, pero también restringen el acceso a otros productos debido a la escasa capacidad de comunicación de datos.

Dado que los conceptos de dominio abarcan toda la empresa, los datos de dominio suelen ser necesarios para otros contextos delimitados de una organización. Las estructuras de comunicación de implementación suelen ser deficientes a la hora de proporcionar este mecanismo de comunicación, aunque sobresalen a la hora de satisfacer las necesidades de su propio contexto delimitado. Influyen en el diseño de los productos de dos maneras. En primer lugar, debido a la ineficacia de la comunicación de los datos de dominio necesarios en toda la organización, desalientan la creación de nuevos productos lógicamente separados. En segundo lugar, facilitan el acceso a los datos de dominio existentes, a riesgo de ampliar continuamente el dominio para abarcar los nuevos requisitos empresariales. Este patrón concreto lo encarnan los diseños monolíticos.

Las estructuras de comunicación de datos desempeñan un papel fundamental en la forma en que una organización diseña y construye productos, pero para muchas organizaciones esta estructura ha estado ausente durante mucho tiempo. Como ya se ha señalado, las estructuras de comunicación de la implementación suelen desempeñar este papel además del suyo propio.

Algunas organizaciones intentan mitigar la incapacidad de acceder a los datos del dominio desde otras implementaciones, pero estos esfuerzos tienen sus propios inconvenientes. Por ejemplo, a menudo se utilizan bases de datos compartidas, aunque éstas promueven con frecuencia antipatrones y a menudo no pueden escalar lo suficiente para adaptarse a todos los requisitos de rendimiento. Las bases de datos pueden proporcionar réplicas de sólo lectura; sin embargo, esto puede exponer innecesariamente sus modelos de datos internos. Los procesos por lotes pueden volcar datos a un almacén de archivos para que los lean otros procesos, pero este enfoque puede crear problemas en torno a la coherencia de los datos y las múltiples fuentes de verdad. Por último, todas estas soluciones dan lugar a un fuerte acoplamiento entre implementaciones y endurecen aún más una arquitectura enrelaciones directas punto a punto.

Precaución

Si descubres que es demasiado difícil acceder a los datos en tu organización o que tus productos están ampliando su alcance porque todos los datos se encuentran en una única implementación, es probable que estés experimentando los efectos de unas estructuras de comunicación de datos deficientes. Este problema se magnificará a medida que la organización crezca, desarrolle nuevos productos y necesite cada vez más acceder a datos de dominio de uso común.

Estructuras de comunicación en la informática tradicional

Las estructuras de comunicación de una organización influyen mucho en cómo se crean las implementaciones de ingeniería. Esto también es cierto a nivel de equipo: las estructuras de comunicación del equipo afectan a las soluciones que construye para los requisitos empresariales específicos que se le asignan. Veamos cómo funciona esto en la práctica.

Considera el siguiente escenario. Un único equipo tiene un único servicio respaldado por un único almacén de datos. Prestan felizmente su función empresarial, y todo va bien en el mundo. Un día, el jefe del equipo llega con un nuevo requisito empresarial. Tiene cierta relación con lo que el equipo ya está haciendo y posiblemente podría añadirse a su servicio actual. Sin embargo, también es lo suficientemente diferente como para convertirse en un nuevo servicio.

El equipo se encuentra en una encrucijada: ¿implementan el nuevo requisito empresarial en un nuevo servicio o simplemente lo añaden a su servicio actual? Veamos sus opciones con un poco más de detalle.

Opción 1: Crear un nuevo servicio

El requisito empresarial es lo suficientemente diferente como para que tenga sentido incluirlo en un nuevo servicio. ¿Pero qué pasa con los datos? Esta nueva función empresarial necesita algunos de los datos antiguos, pero esos datos están actualmente bloqueados en el servicio existente. Además, el equipo no tiene realmente un proceso para lanzar nuevos servicios totalmente independientes. Por otra parte, el equipo se está haciendo un poco grande, y la empresa crece rápidamente. Si el equipo tiene que dividirse en el futuro, tener sistemas modulares e independientes puede facilitar mucho el reparto de la propiedad.

Hay riesgos asociados a este enfoque. El equipo debe encontrar la forma de obtener datos de su almacén de datos original y copiarlos en su nuevo almacén de datos. Tienen que asegurarse de no exponer el funcionamiento interno y de que los cambios que hagan en sus estructuras de datos no afectarán a ningún otro equipo que copie sus datos. Además, los datos que se copien siempre estarán algo obsoletos, ya que sólo pueden permitirse copiar los datos de producción en tiempo real cada 30 minutos para no saturar el almacén de datos con consultas. Esta conexión deberá ser monitoreada y mantenida para garantizar que funciona correctamente.

También existe el riesgo de poner en marcha un nuevo servicio. Tendrán que gestionar dos almacenes de datos y dos servicios, y establecer para ellos procesos de registro, monitoreo, pruebas, implementación y reversión. También deben tener cuidado de sincronizar cualquier cambio en la estructura de datos para que no afecte al sistema dependiente.

Opción 2: Añádelo al servicio existente

La otra opción es crear las nuevas estructuras de datos y la lógica empresarial dentro del servicio existente. Los datos necesarios ya están en el almacén de datos, y los procesos de registro, monitoreo, pruebas, implementación y reversión ya están definidos y en uso. El equipo está familiarizado con el sistema y puede ponerse a trabajar directamente en la implementación de la lógica, y sus patrones monolíticos apoyan este enfoque del diseño del servicio.

También hay riesgos asociados a este enfoque, aunque son un poco más sutiles. Los límites dentro de la implementación pueden desdibujarse a medida que se realizan cambios, sobre todo porque los módulos a menudo se agrupan en la misma base de código. Es demasiado fácil añadir funciones rápidamente cruzando esos límites y acoplándose directamente a través del módulo. Moverse con rapidez es una gran ventaja, pero tiene el coste de acoplamientos estrechos, menor cohesión y falta de modularidad. Aunque los equipos pueden evitarlo, se requiere una planificación excelente y un cumplimiento estricto de los límites, que a menudo se quedan por el camino ante los plazos ajustados, la inexperiencia y los cambios enla propiedad del servicio.

Ventajas e inconvenientes de cada opción

La mayoría de los equipos elegirían la segunda opción: añadir la funcionalidad al sistema existente. Esta elección no tiene nada de malo; las arquitecturas monolíticas son estructuras útiles y potentes y pueden aportar un valor excepcional a una empresa. La primera opción choca de frente con los dos problemas asociados a la informática tradicional:

• Acceder a los datos de otro sistema es difícil de hacer de forma fiable, sobre todo a escala y en tiempo real.

• Crear y gestionar nuevos servicios lleva asociados unos gastos generales y un riesgo considerables, sobre todo si no hay una forma establecida de hacerlo dentro de la organización.

Acceder a los datos locales siempre es más fácil que acceder a los datos de otro almacén de datos. Cualquier dato encapsulado en el almacén de datos de otro equipo es difícil de obtener, ya que requiere cruzar los límites de la implementación y de la comunicación empresarial. Esto resulta cada vez más difícil de mantener y escalar a medida que crecen los datos, el número de conexiones y los requisitos de rendimiento.

Aunque copiar los datos necesarios es un enfoque valioso, no es infalible. Este modelo fomenta muchos acoplamientos directos punto a punto, que se vuelven problemáticos de mantener a medida que una organización crece, las unidades de negocio y la propiedad cambian, y los productos maduran y se retiran. Crea una estricta dependencia técnica las estructuras de comunicación de implementación de ambos equipos (el equipo que almacena los datos y el equipo que los copia), exigiéndoles que trabajen de forma sincronizada siempre que se produzca un cambio en los datos. Hay que tener especial cuidado para que el modelo de datos interno de una implementación no quede indebidamente expuesto, no sea que otros sistemas se acoplen estrechamente a él. La escalabilidad, el rendimiento y la disponibilidad del sistema suelen ser problemas para ambos sistemas, ya que la consulta de replicación de datos puede suponer una carga insostenible para el sistema de origen. Los procesos de sincronización fallidos pueden no advertirse hasta que se produce una emergencia. El conocimiento tribal puede dar lugar a que un equipo copie una copia de los datos, pensando que es la fuente original de la verdad.

Los datos copiados siempre estarán algo obsoletos cuando se complete la consulta y se transfieran los datos. Cuanto mayor sea el conjunto de datos y más complejo su origen, más probable será que una copia no esté sincronizada con el original. Esto es problemático cuando los sistemas esperan que los demás tengan copias perfectas y actualizadas, sobre todo cuando se comunican entre sí sobre esos datos. Por ejemplo, un servicio de informes puede informar de valores diferentes a los de un servicio de facturación debido a la falta de actualización. Esto puede tener graves consecuencias para la calidad del servicio, los informes, los análisis y la toma de decisiones monetarias.

La incapacidad de difundir correctamente los datos por toda la empresa no se debe a un defecto fundamental del concepto. Todo lo contrario: se debe a una estructura de comunicación de datos débil o inexistente. En el escenario anterior, la estructura de comunicación de la implementación del equipo está cumpliendo una doble función como estructura de comunicación de datos extremadamente limitada.

Consejo

Uno de los principios de los microservicios basados en eventos es que los datos empresariales básicos deben ser fáciles de obtener y utilizables por cualquier servicio que los necesite. Esto sustituye la estructura de comunicación de datos ad hoc de este escenario por una estructura de comunicación de datos formalizada. Para el equipo hipotético, esta estructura de comunicación de datos podría eliminar la mayoría de las dificultades para obtener datos de otros sistemas.

El escenario del equipo, continuación

Avanzamos un año. El equipo decidió optar por la opción 2 e incorporar las nuevas funciones dentro del mismo servicio. Fue rápido, fue fácil, y desde entonces han implementado varias funciones nuevas. A medida que la empresa ha ido creciendo, el equipo también lo ha hecho, y ahora ha llegado el momento de reorganizarlo en dos equipos más pequeños y centrados.

Ahora hay que asignar a cada nuevo equipo determinadas funciones empresariales del servicio anterior. Los requisitos empresariales de cada equipo están claramente divididos en función de las áreas de la empresa que necesitan más atención. Sin embargo, dividir la estructura de comunicación de la implantación no está resultando fácil. Al igual que antes, parece que ambos equipos necesitan grandes cantidades de los mismos datos para cumplir sus requisitos. Surgen nuevas series de preguntas:

• ¿Qué equipo debe poseer qué datos?

• ¿Dónde deben residir los datos?

• ¿Qué ocurre con los datos en los que ambos equipos deben modificar los valores?

Los jefes de equipo deciden que quizá sea mejor compartir el servicio, y que ambos pueden trabajar en distintas partes. Esto requerirá mucha más comunicación entre equipos y sincronización de esfuerzos, lo que puede ser un lastre para la productividad. ¿Y qué pasa en el futuro, si vuelven a duplicar su tamaño? ¿O si los requisitos empresariales cambian lo suficiente como para que ya no puedan cumplir todo con la misma estructura de datos?

Presiones contradictorias

Hay dos presiones contradictorias sobre el equipo original. Se vio influido a mantener todos sus datos locales en un servicio para que añadir nuevas funciones empresariales fuera más rápido y fácil, a costa de ampliar la estructura de comunicación de la implementación. Finalmente, el crecimiento del equipo hizo necesaria la división de la estructura de comunicación empresarial, requisito al que siguió la reasignación de los requisitos empresariales a los nuevos equipos. La estructura de comunicación de implementación, sin embargo, no puede soportar las reasignaciones en su forma actual y necesita dividirse en componentes adecuados. Ninguno de los dos enfoques es escalable, y ambos apuntan a la necesidad de hacer las cosas de otra manera. Todos estos problemas tienen el mismo origen: un medio débil y mal definido de comunicar datos entre estructuras de comunicación de implementación.

Estructuras de comunicación basadas en sucesos

El enfoque basado en eventos ofrece una alternativa al comportamiento tradicional de las estructuras de implementación y comunicación de datos. Las comunicaciones basadas en eventos no son un sustituto de las comunicaciones solicitud-respuesta, sino una forma completamente distinta de comunicarse entre servicios. Una estructura de comunicación de datos basada en eventos desvincula la producción y propiedad de los datos del acceso a los mismos. Los servicios ya no se acoplan directamente a través de una API de solicitud-respuesta, sino a través de datos de eventos definidos dentro de flujos de eventos (este proceso se trata con más detalle en el Capítulo 3). Las responsabilidades de los productores se limitan a producir datos bien definidos en sus respectivos flujos de eventos.

Los acontecimientos son la base de la comunicación

Todos los datos compartibles se publican en un conjunto de flujos de eventos, formando una narración continua y canónica que detalla todo lo que ha ocurrido en la organización. Esto se convierte en el canal por el que los sistemas se comunican entre sí. Casi cualquier cosa puede comunicarse como un evento, desde simples sucesos hasta registros complejos con estado. Los eventos son los datos; no son meras señales que indican que los datos están listos en otro lugar o sólo un medio de transferencia directa de datos de una implementación a otra. Más bien, actúan a la vez como almacenamiento de datos y como medio de comunicación asíncrona entre servicios.

Los flujos de eventos proporcionan la única fuente de verdad

Cada evento de un flujo es una declaración de hechos, y juntos forman la única fuente de verdad, la base de la comunicación de todos los sistemas de la organización. Una estructura de comunicación sólo es tan buena como la veracidad de su información, por lo que es fundamental que la organización adopte la narración del flujo de eventos como única fuente de verdad. Si algunos equipos eligen en su lugar colocar datos contradictorios en otras ubicaciones, la función del flujo de eventos como columna vertebral de las comunicaciones de datos de la organización se ve significativamente mermada.

Los consumidores realizan sus propios modelos y consultas

La estructura de comunicación de datos basada en eventos difiere de una estructura de comunicación de aplicación sobredimensionada en que es incapaz de proporcionar ninguna funcionalidad de consulta o búsqueda de datos. Toda la lógica empresarial y de aplicación debe estar encapsulada en el productor y el consumidor de los eventos.

El acceso a los datos y los requisitos de modelado se trasladan completamente al consumidor, y cada consumidor obtiene su propia copia de los eventos de los flujos de eventos de origen. Cualquier complejidad de consulta también se traslada de la estructura de comunicación de implementación del propietario de los datos a la del consumidor. El consumidor sigue siendo plenamente responsable de cualquier mezcla de datos de múltiples flujos de eventos, funcionalidad de consulta especial u otra lógica de implementación específica del negocio. Por lo demás, tanto productores como consumidores quedan liberados de su obligación de proporcionar mecanismos de consulta, mecanismos de transferencia de datos, API (interfaces de programación de aplicaciones) y servicios entre equipos para los medios de comunicación de datos. Ahora su responsabilidad se limita a resolver las necesidades de su contexto limitado inmediato.

Se mejora la comunicación de datos en toda la organización

El uso de una estructura de comunicación de datos es una inversión, ya que todos los datos compartibles se exponen fuera de la estructura de comunicación de la aplicación. No todos los datos deben compartirse y, por tanto, no todos deben publicarse en el conjunto de flujos de eventos. Sin embargo, cualquier dato que sea de interés para cualquier otro equipo o servicio debe publicarse en el conjunto común de flujos de eventos, de modo que la producción y la propiedad de los datos se desacoplan totalmente. Esto proporciona la estructura formalizada de comunicación de datos que ha faltado durante mucho tiempo en las arquitecturas de sistemas y se adhiere mejor a los principios de contexto limitado de acoplamiento flexible y alta cohesión.

Ahora las aplicaciones pueden acceder a datos que de otro modo habría sido laborioso obtener mediante conexiones punto a punto. Los nuevos servicios pueden simplemente adquirir cualquier dato necesario de los flujos de eventos canónicos, crear sus propios modelos y estado, y realizar cualquier función empresarial necesaria sin depender de conexiones directas punto a punto o API con ningún otro servicio. Esto desbloquea el potencial de una organización para utilizar más eficazmente sus enormes cantidades de datos en cualquier producto, e incluso mezclar datos de múltiples productos de formas únicas y potentes.

Los datos accesibles apoyan los cambios en la comunicación empresarial

Los flujos de eventos contienen eventos del dominio central que son fundamentales para el funcionamiento de la empresa. Aunque los equipos se reestructuren y los proyectos vayan y vengan, los datos importantes del dominio central siguen estando fácilmente disponibles para cualquier nuevo producto que los necesite, independientemente de cualquier estructura de comunicación de implementación específica. Esto proporciona a la empresa una flexibilidad sin precedentes, ya que el acceso a los eventos del dominio central ya no depende de ninguna implementación concreta.

Microservicios asíncronos basados en eventos

Los microservicios basados en eventos permiten las transformaciones y operaciones de lógica empresarial necesarias para cumplir los requisitos del contexto delimitado. Estas aplicaciones se encargan de cumplir estos requisitos y de emitir los eventos propios que sean necesarios a otros consumidores posteriores. He aquí algunas de las principales ventajas de utilizar microservicios basados en eventos:

Granularidad

Los servicios se asignan claramente a contextos delimitados y pueden reescribirse fácilmente cuando cambian los requisitos empresariales.

Escalabilidad

Los servicios individuales pueden ampliarse o reducirse según las necesidades.

Flexibilidad tecnológica

Los servicios utilizan los lenguajes y tecnologías más adecuados. Esto también permite crear prototipos fácilmente utilizando tecnología pionera.

Flexibilidad de los requisitos empresariales

La propiedad de microservicios granulares es fácil de reorganizar. Hay menos dependencias entre equipos en comparación con los grandes servicios, y la organización puede reaccionar más rápidamente a los cambios en los requisitos empresariales que, de otro modo, se verían obstaculizados por las barreras de acceso a los datos.

Acoplamiento débil

Los microservicios basados en eventos se acoplan a los datos del dominio y no a una API de implementación específica. Los esquemas de datos pueden utilizarse para mejorar en gran medida la gestión de los cambios de datos, como se verá en el Capítulo 3.

Apoyo a la entrega continua

Es fácil lanzar un microservicio pequeño y modular, y hacerlo retroceder si es necesario.

Alta comprobabilidad

Los microservicios suelen tener menos dependencias que los grandes monolitos, por lo que es más fácil simular los puntos finales de prueba necesarios y garantizar unacobertura de código adecuada.

Ejemplo de equipo que utiliza microservicios dirigidos por eventos

Volvamos al equipo de antes, pero con una estructura de comunicación de datos basada en eventos.

Se presenta al equipo un nuevo requisito empresarial. Está relacionado de algún modo con lo que hacen sus productos actuales, pero también es lo suficientemente diferente como para que pudiera ir en un servicio propio. ¿Añadirlo a un servicio existente viola el principio de responsabilidad única y amplía demasiado el contexto delimitado definido actualmente? ¿O se trata de una simple extensión, tal vez la adición de algunos nuevos datos o funciones relacionados, de un servicio existente?

Los problemas técnicos anteriores -como averiguar de dónde obtener los datos y cómo almacenarlos, resolver problemas de sincronización por lotes e implementar API síncronas- han desaparecido en gran medida. El equipo puede poner en marcha un nuevo microservicio e ingerir los datos necesarios de los flujos de eventos, remontándose hasta el principio de los tiempos si es necesario. Es totalmente posible que el equipo mezcle datos comunes utilizados en sus otros servicios, siempre que esos datos se utilicen únicamente para satisfacer las necesidades del nuevo contexto delimitado. El almacenamiento y la estructura de estos datos se dejan totalmente a criterio del equipo, que puede elegir qué campos conservar y cuáles descartar.

También se alivian los riesgos empresariales, ya que los servicios pequeños y de grano más fino permiten la propiedad de un solo equipo, lo que permite a los equipos escalar y reorganizarse según sea necesario. Cuando el equipo crece demasiado como para gestionarlo bajo un único propietario empresarial, pueden dividirse según sea necesario y reasignar la propiedad del microservicio. La propiedad de los datos de eventos se desplaza con el servicio productor, y pueden tomarse decisiones organizativas para reducir la cantidad de comunicación entre equipos necesaria para realizar el trabajo futuro.

La naturaleza del microservicio impide que se arraigue el código espagueti y los monolitos expansivos, siempre que la sobrecarga para crear nuevos servicios y obtener los datos necesarios sea mínima. La preocupación por el escalado se centra ahora en los servicios individuales de procesamiento de eventos, que pueden escalar su CPU, memoria, disco y número de instancias según sea necesario. El resto de los requisitos de escalado se descargan en la estructura de comunicación de datos, que debe asegurarse de que puede gestionar las distintas cargas de servicios que consumen y producen sus flujos de eventos.

Para hacer todo esto, sin embargo, el equipo necesita asegurarse de que los datos están realmente presentes en la estructura de comunicación de datos, y debe disponer de los medios para poner en marcha y gestionar fácilmente una flota de microservicios. Esto requiere una adopción de la arquitectura EDM en toda la organización.

Microservicios Síncronos

Los microservicios pueden implementarse de forma asíncrona utilizando eventos (el enfoque que defiende este libro) o síncrona, lo que es habitual en las arquitecturas orientadas a servicios. Los microservicios síncronos tienden a cumplirse utilizando un enfoque de petición-respuesta, en el que los servicios se comunican directamente a través de API para cumplir los requisitos empresariales.

Inconvenientes de los microservicios síncronos

Hay una serie de problemas con los microservicios síncronos que dificultan su uso a gran escala. Esto no quiere decir que una empresa no pueda tener éxito utilizando microservicios síncronos, como demuestran los logros de empresas como Netflix, Lyft, Uber y Facebook. Pero muchas empresas también han hecho fortunas utilizando monolitos de código espagueti arcaicos y horriblemente enmarañados, así que no confundas el éxito final de una empresa con la calidad de su arquitectura subyacente. Hay varios libros que describen cómo implementar microservicios síncronos, así que te recomiendo que los leas para comprender mejor los enfoques síncronos.¹

Además, ten en cuenta que ni los microservicios punto a punto de solicitud-respuesta ni los microservicios asíncronos basados en eventos son estrictamente mejores que los otros. Ambos tienen su lugar en una organización, ya que algunas tareas se adaptan mucho mejor a uno que a otro. Sin embargo, mi propia experiencia, así como la de muchos de mis compañeros y colegas, indica que las arquitecturas EDM ofrecen una flexibilidad sin igual que está ausente en los microservicios síncronos de petición-respuesta. Tal vez llegues a estar de acuerdo a medida que avances en este libro, pero al menos comprenderás sus puntos fuertes y sus inconvenientes.

He aquí algunas de las mayores deficiencias de los microservicios síncronos de petición-respuesta.

Acoplamientos punto a punto

Los microservicios síncronos dependen de otros servicios para ayudarles a realizar sus tareas empresariales. Esos servicios, a su vez, tienen sus propios servicios dependientes, que a su vez tienen sus propios servicios dependientes, y así sucesivamente. Esto puede dar lugar a un excesivo fanout y a dificultades para rastrear qué servicios son responsables de cumplir partes específicas de la lógica empresarial. El número de conexiones entre servicios puede llegar a ser asombrosamente alto, lo que afianza aún más las estructuras de comunicación existentes y dificulta los cambios futuros.

Escala dependiente

La capacidad de escalar tu propio servicio depende de la capacidad de todos los servicios dependientes para escalar también y está directamente relacionada con el grado de fanout de las comunicaciones. Las tecnologías de implementación pueden ser un cuello de botella para la escalabilidad. Esto se complica aún más por las cargas muy variables y los patrones de peticiones en aumento, que deben gestionarse de forma sincrónica en toda la arquitectura.

Gestión de fallos de servicio

Si un servicio dependiente se cae, hay que tomar decisiones sobre cómo gestionar la excepción. Decidir cómo gestionar las interrupciones, cuándo reintentar, cuándo fallar y cómo recuperarse para garantizar la coherencia de los datos resulta cada vez más difícil cuantos más servicios haya en el ecosistema.

Gestión de versiones y dependencias de la API

A menudo será necesario que existan varias definiciones de API y versiones de servicio al mismo tiempo. No siempre es posible o deseable obligar a los clientes a actualizarse a la API más reciente. Esto puede añadir mucha complejidad a la orquestación de las solicitudes de cambio de API en múltiples servicios, especialmente si van acompañadas de cambios en las estructuras de datos subyacentes.

Acceso a los datos vinculado a la aplicación

Los microservicios síncronos tienen los mismos problemas que los servicios tradicionales cuando se trata de acceder a datos externos. Aunque existen estrategias de diseño de servicios paramitigar la necesidad de acceder a datos externos, a menudo los microservicios seguirán necesitando acceder a datos de uso común de otros servicios. Esto devuelve la carga del acceso a los datos y la escalabilidad a la estructura de comunicación de la implementación.

Monolitos distribuidos

Los servicios pueden componerse de forma que actúen como un monolito distribuido, con muchas llamadas entrelazadas entre ellos. Esta situación suele darse cuando un equipo está descomponiendo un monolito y decide utilizar llamadas síncronas punto a punto para imitar los límites existentes dentro de su monolito. Los servicios punto a punto facilitan la difuminación de las líneas entre los contextos delimitados, ya que las llamadas a funciones de sistemas remotos pueden encajar línea a línea con el código existente del monolito.

Prueba

Las pruebas de integración pueden ser difíciles, ya que cada servicio requiere dependientes plenamente operativos, que a su vez requieren los suyos propios. Eliminarlos puede funcionar para las pruebas unitarias, pero rara vez resulta suficiente para requisitos de pruebas más amplios.

Ventajas de los microservicios síncronos

Los microservicios síncronos aportan una serie de ventajas innegables. Ciertos patrones de acceso a datos son favorables a los acoplamientos directos solicitud-respuesta, como autenticar a un usuario e informar sobre una prueba AB. Las integraciones con soluciones externas de terceros casi siempre utilizan un mecanismo síncrono y, por lo general, proporcionan un mecanismo de comunicación flexible e independiente del lenguaje a través de HTTP.

Rastrear operaciones en varios sistemas puede ser más fácil en un entorno síncrono que en uno asíncrono. Los registros detallados pueden mostrar qué funciones fueron llamadas en qué sistemas, lo que permite una gran depurabilidad y visibilidad de las operaciones empresariales.

Los servicios que alojan experiencias web y móviles se basan en general en diseños de solicitud-respuesta, independientemente de su naturaleza sincrónica o asincrónica. Los clientes reciben una respuesta oportuna dedicada íntegramente a sus necesidades.

El factor experiencia también es bastante importante, sobre todo porque muchos desarrolladores del mercado actual tienden a tener mucha más experiencia con la codificación síncrona de estilo monolítico. Esto hace que la adquisición de talento para sistemas síncronos sea más fácil, en general, que la adquisición de talento para el desarrollo asíncrono basado en eventos.

Consejo

La arquitectura de una empresa rara vez, o nunca, se basará totalmente en microservicios basados en eventos. Las arquitecturas híbridas serán sin duda la norma, en las que las soluciones síncronas y asíncronas se desplieguen codo con codo, según lo requiera el espacio del problema.

Resumen

Las estructuras de comunicación dirigen cómo se crea y gestiona el software a lo largo de la vida de una organización. Las estructuras de comunicación de datos suelen estar poco desarrolladas y ser ad hoc, pero la introducción de un conjunto de eventos de dominio duradero y de fácil acceso, como el que encarnan los sistemas dirigidos por eventos, permite utilizar implementaciones más pequeñas y creadas a propósito.

¹ Véase, por ejemplo, Building Microservices de Sam Newman (O'Reilly, 2015) y Microservices for the Enterprise de Kasun Indrasiri y Prabath Siriwardena (Apress, 2018).