Arquitecturas de integración

El panorama tecnológico está en constante cambio y, como arquitecto, se enfrenta a herramientas y tecnologías modernas todos los días. Algunos de estos enfoques de integración se están volviendo menos populares hoy en día, pero sus conceptos siguen siendo la base de otros enfoques más modernos. En mi experiencia, los entusiastas de la tecnología pueden dejarse llevar por nuevos conceptos y terminologías. Y, si bien es muy importante mantenerse al día con las últimas y más grandes tendencias del mercado, como arquitecto senior, es importante comprender cuáles de estos enfoques son los más adecuados para cada proyecto.

Arquitectura orientada a Servicios (SOA)

La arquitectura orientada a servicios (SOA) es un enfoque de desarrollo de software que tiene como objetivo encapsular la lógica empresarial en un servicio que aprovecha al máximo el código reutilizable. Cada servicio contiene el código y las integraciones de datos necesarios para cumplir con un caso de uso comercial en particular; por ejemplo, realizar un pedido de compra o incorporar a un nuevo cliente.

Estos servicios están débilmente acoplados y utilizan un bus de servicio empresarial para comunicarse entre sí. Esto significa que los desarrolladores pueden ahorrar tiempo reutilizando los servicios SOA existentes en toda la empresa.

Los servicios SOA son representaciones lógicas de actividades comerciales particulares con resultados específicos claros. Se proporcionan más o menos como una caja negra para los consumidores que no necesitan preocuparse por cómo funcionan estos servicios. Los servicios pueden constar de varios otros servicios subyacentes.

SOA surgió a fines de la década de 1990 y fue la base para otros enfoques de integración modernos, como los microservicios y la arquitectura impulsada por eventos. Algunos críticos de SOA mencionan desafíos con respecto a su rendimiento, mantenibilidad y las dificultades asociadas con diseñarlo con el nivel correcto de granularidad.

Microservicios

Los microservicios son una interpretación moderna de SOA. También están formados por componentes reutilizables y con débil acoplamiento con una funcionalidad y un resultado claros. En lugar de comunicarse a través de un ESB, los microservicios se comunican entre sí directamente. Los servicios pueden utilizar diferentes tecnologías y protocolos.

La arquitectura de microservicios está muy orientada hacia la nube. Utiliza los conceptos de Desarrollo y Operaciones (DevOps) para permitir que los pequeños equipos descentralizados se apropien por completo de un servicio en particular, brinden su funcionalidad usando su tecnología preferida y la liberen rápidamente a la empresa usando contenedores livianos.

Los microservicios se utilizan normalmente como componentes básicos para otras aplicaciones empresariales. Son servicios muy específicos y tienen acceso a sus propios almacenes de datos para acceder a todos los datos a los que necesitan acceder. Se supone que los microservicios nunca deben acceder al mismo almacén de datos / base de datos, ya que esto crearía una dependencia entre ellos y cualquier otro almacén de datos. Los principios de microservicios favorecen la encapsulación y la independencia sobre la reutilización; el código redundante se considera un efecto secundario aceptable.

Los microservicios se hicieron populares desde su introducción en 2014 debido a su relación con los conceptos de DevOps. 

Diferencias entre SOA y microservicios

Debido a la similitud entre SOA y microservicios, es bueno comprender algunas de las diferencias clave entre estos enfoques de integración particulares:

• Llamadas síncronas: los servicios SOA reutilizables deben estar disponibles en toda la empresa mediante el uso de protocolos síncronos como SOAP o API REST. Las llamadas síncronas son menos preferidas en la arquitectura de microservicios, ya que pueden crear dependencias en tiempo real, lo que puede provocar latencia. Se prefiere un enfoque asincrónico, como publicar / suscribir, que mejoraría la resistencia y disponibilidad de los servicios.
• Comunicación: los servicios SOA utilizan ESB para comunicarse, lo que podría convertir a ESB en un cuello de botella en el rendimiento. Los microservicios se desarrollan de forma independiente y se comunican directamente utilizando diferentes protocolos y estándares.
• Reutilización: SOA se trata de aumentar la reutilización, mientras que en la arquitectura de microservicios, esto es menos importante, especialmente si se tiene en cuenta que lograr cierta reutilización en tiempo de ejecución podría crear dependencias entre los microservicios, lo que reduce la agilidad y la resiliencia. Con los microservicios, duplicar código copiando y pegando se considera un efecto secundario aceptado para evitar dependencias.
• Duplicación de datos: en SOA, los servicios pueden acceder directamente y modificar los datos en una aplicación o fuente de datos en particular. Esto significa que es probable que varios servicios SOA accedan al mismo almacén de datos. Los microservicios siempre apuntan a reducir las dependencias. Idealmente, un microservicio debería tener acceso local a todos los datos que necesita para ofrecer la funcionalidad esperada. Esto significa que puede ser necesario duplicar algunos datos. Esto también significa que los datos podrían estar desincronizados entre los diferentes servicios. La duplicación de datos agrega una cantidad considerable de complejidad al diseño y al uso potencial de los microservicios, por lo que debe equilibrarse con las ganancias esperadas de la independencia del microservicio.
• Granularidad: los microservicios están diseñados para realizar una tarea específica; son muy especializados y, por lo tanto, de grano fino. Por otro lado, los servicios SOA reflejan los servicios empresariales, por lo que pueden abarcar desde servicios empresariales pequeños a más grandes.
• Velocidad: como mencionamos anteriormente, la velocidad era uno de los lados más débiles de SOA debido a varios factores. Los microservicios son livianos, más especializados y, por lo general, utilizan protocolos de comunicación livianos como REST. Por lo general, se ejecutan más rápido que los servicios SOA.

Arquitectura dirigida por API

La arquitectura dirigida por API es una estrategia de API donde todos los servicios externos e internos se exponen como API administradas, independientemente de cómo se implementaron (microservicios, servicios SOA, servicios web impulsados ​​desde una aplicación monolítica o basados ​​en otras arquitecturas). Las API administradas en los términos modernos de hoy en día hacen más que solo proporcionar capacidades de gobierno como políticas de seguridad, limitación, control de versiones y descubrimiento automático de servicios. El principio se ha extendido más allá de eso para incluir portales de desarrolladores donde pueden experimentar con API antes de usarlas, herramientas de productividad y un mecanismo para registrarse y pagar por el uso de API. En este enfoque, las API generalmente se organizan en tres capas diferentes:

• API del sistema: están destinadas a acceder a sistemas y servicios centrales. Proporcionan una capa aislante simplificada entre el consumidor del servicio y el sistema o servicio subyacente.
• API de proceso: están destinadas a interactuar, transformar y dar forma a los datos que provienen de las API del sistema subyacente o de otras API de proceso, rompiendo efectivamente los silos de datos. No dependen de los sistemas de origen de donde provienen los datos, ni de los sistemas de destino donde se entregarán los datos. Tanto las API del sistema como las API de proceso se pueden utilizar para conectarse a microservicios existentes, así como a otros servicios empresariales, según el caso de uso.
• API de experiencia: están diseñadas para permitir un fácil acceso y consumo de datos para el usuario final o la aplicación. Por lo general, se comunican con una o más API de proceso para ofrecer una funcionalidad específica.

Se sabe que los microservicios crean muchos puntos finales, que normalmente son difíciles de controlar y monetizar. La arquitectura dirigida por API tiene como objetivo crear una estrategia de API que gobierne la forma en que los diferentes servicios empresariales interactúan entre sí, así como con los consumidores externos, utilizando las capacidades de estándares ligeros como REST y combinándolos con capacidades de API gateway modernas.

Arquitectura Orientada a Eventos

La arquitectura orientada a eventos es un enfoque de desarrollo de software que utiliza eventos para comunicarse y desencadenar acciones en aplicaciones integradas y desacopladas. Un evento es simplemente un cambio en el estado de un objeto en particular. Por ejemplo, un cambio en el valor del estado del cliente podría desencadenar un evento de cambio de estado del cliente que, a su vez, desencadenaría un conjunto de acciones en los sistemas integrados, como iniciar un viaje de marketing en particular.

La arquitectura impulsada por eventos hereda algunos principios del estilo de integración de mensajería, como mencionamos anteriormente. La arquitectura impulsada por eventos tiene tres componentes principales: productores de eventos, enrutadores de eventos y consumidores de eventos. Los productores publican eventos en el enrutador, los enrutadores manejan el filtrado y el envío de eventos a los consumidores suscritos, y los consumidores reciben el evento, lo analizan y lo transforman en un formato adecuado para sus necesidades, y luego lo usan, generalmente para actualizar su propia versión de los datos o para disparar la lógica posterior. Las plataformas de procesamiento de flujo, los ESB modernos o los buses de enrutamiento de eventos como CometD se utilizan generalmente como enrutadores.