Skip to main content
Microservicios Vs ESB

Microservicios y ESB, ¿amigos o enemigos?

1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (Ninguna valoración todavía)
Cargando…

Las arquitecturas de microservicios son la evolución lógica en el perfeccionamiento de las arquitecturas SOA dentro del mundo empresarial. Dichas arquitecturas se ven impulsadas por dos conceptos clave: un menor “time to market” y una mejora dentro del ámbito de la continuidad de negocio.

La reducción del “time to market” se debe a que la funcionalidad desarrollada en un microservicio sigue el principio de responsabilidad única, gracias al cual se evitan retrasos devenidos de la inclusión de la nueva funcionalidad en grandes aplicativos monolíticos. Por otro lado, nos libramos también de las integraciones “big bang” con dolorosos pases a producción en los que, errores de distintas partes del monolito podían repercutir en la nueva funcionalidad independiente que estamos incorporando, por el denominado efecto de “bola de nieve”.

Otra consecuencia del principio de responsabilidad única en las arquitecturas de microservicios es la mejora de los RTO (Recovery Time Objetive) dentro del campo de la continuidad de negocio. Los activos se encuentran más focalizados, al ser responsablemente independientes, y por este motivo, ya no se requeriría recuperar grandes servidores de aplicaciones con grandes despliegues, a causa de que una sola parte del mismo no funcionase correctamente, debido a fallos en la infraestructura o en las propias aplicaciones.

Estos dos conceptos claves que están impulsando las arquitecturas de microservicios y que las están haciendo tan populares han conseguido que haya ámbitos en losque dichas arquitecturas no se consideren como SOA. Esto es debido a las malas prácticas en la implementación y al uso de patrones de diseño SOA que van, desde cajones de sastre en forma de ESB (Enterprise Service Bus), que incluyen lógica de negocio, hasta integraciones con verdaderos aplicativos monolíticos monstruosos. Pero, ¿debemos considerar las arquitecturas de microservicios como algo independiente? ¿Siguen siendo buenos los patrones de diseño como el ESB o se les debería considerar patrones en decadencia como los empiezan a considerar algunos autores?

 

Antes de empezar, ¿qué es un microservicio?

Como ya se ha comentado, un microservicio es un aplicativo que cumple con el principio de responsabilidad única. Pero, ¿qué es realmente el principio de responsabilidad única? A continuación se describe un símil a modo de ejemplo que es bastante descriptivo en este aspecto.

Imaginemos que dentro de una empresa disponemos de un empleado que concentra el conocimiento de múltiples tecnologías y es, sólo él, quien dispone de dicho conocimiento. Si surgen múltiples proyectos, dicha persona se convertiría en el cuello de botella de los mismos, y si se diese el casual de que se pone malo o abandona la empresa, nos enfrentaríamos al problema de encontrar un perfil técnico tan amplio como para cubrir gran responsabilidad, concentrada en una única persona. Es decir, un tiempo de recuperación ante fallo (RTO) bastante alto. Éste empleado, entonces, se podría considerar un contenedor de aplicaciones con una enorme aplicación monolítica.

Si por otro lado, disponemos de un empleado focalizado en desarrollar sólo servicios REST, podríamos ampliar el equipo bajo carga de trabajo más fácilmente, ya que sólo sería necesario contratar empleados con la responsabilidad única de desarrollo de servicios REST. Es decir, consideraríamos a dicho empleado como un microservicio. Esto permite un equipo más escalable bajo carga de trabajo y, obviamente, una mejor gestión de nuestros recursos si nos apoyamos en un dimensionamiento basado en la teoría matemática de colas. Si por el mismo casual, dicho empleado abandonase la empresa, ¿sería más fácil encontrar a alguien que concentre el conocimiento de múltiples tecnologías o a alguien que dispone de responsabilidad en una sola?

Apoyándose en dicho principio, dentro de las arquitecturas de microservicios, Martin Fowler realiza una descripción muy interesante acerca de microservicios testeables en la que plantea una arquitectura divida en las mismas capas que ya conocemos dentro de las arquitecturas de aplicaciones convencionales. En la siguiente figura se puede observar dicha arquitectura.

 MartinFowlerMicroservices

En la imagen anterior podemos apreciar el límite lógico como la implementación de la responsabilidad del aplicativo, independiente del resto del sistema.

Por otro lado, como un microservicio puede requerir acceso a almacenes de datos o servicios externos, se acota un límite definido por la red. Es en dicho límite donde las referencias a esos servicios y almacenes de datos externos se simulan, para proporcionar al microservicio la capacidad de ser testeable de manera independiente.

Ahora bien, disponemos de una arquitectura similar a la que disponíamos en las arquitecturas monolíticas, más fácilmente testeables eso sí, pero de igual modo con capacidad de acceso a fuentes de datos y servicios externos. ¿Es el cambio de filosofía mediante el principio de responsabilidad única suficiente para considerar los microservicios como algo independiente de las arquitecturas SOA? Las respuesta a esta pregunta es bastante sencilla: los microservicios son un patrón de diseño que permiten construir arquitecturas SOA, pero esta vez sí, bien hechas.

 

Entonces, ¿llegó la decadencia del ESB?

De igual modo que los microservicios, el ESB es un patrón de diseño y como tal, no puede entrar en decadencia.

Las distintas herramientas que implementan dicho patrón y su utilización indiscriminada, ya sea por el coste de licenciamiento, o por desconocimiento de los roles competencia de dicho patrón, mostrados en la siguiente figura, han conseguido que la gente vea dicho patrón como la antítesis de los patrones SOA, y por lo tanto, algo a eliminar con los microservicios.

 ESB_SOAPatterns

 

En las arquitecturas de microservicios, éstos suelen exponer sus recursos como servicios REST/JSON y gracias al principio de responsabilidad única, dichos microservicios disponen de una gran capacidad de escalabilidad horizontal.

Debido a esto, el patrón ESB se aligera de responsabilidad, ya que no requiere cambios de protocolos ni costosas transformaciones de modelos de datos o de formatos, ya que todos los microservicios expondrán un API REST. Ésto permite que las mediaciones y enrutados a través del ESB sean mucho más ligeros y que el ESB por fin cumpla su funcionalidad concreta de mediación y no de ente sobrecargado de funcionalidad de negocio.

Por este motivo, si a una arquitectura escalable de microservicios y al enrutado dinámico del ESB, le añadimos un registro en el que se registre dónde está cada microservicio, éste registro podría ser consultado por el ESB y, de este modo, ser completamente transparente para el cliente que invoca al ESB del número de recursos que está proporcionando la funcionalidad solicitada.

 

Arquitecturas Canary: Microservicios y ESB trabajando juntos

Un caso de uso bastante interesante que ilustra cómo los microservicios y el ESB trabajan de manera colaborativa con un fin común sería las arquitecturas de “canary release”. En estas arquitecturas, lo que se persigue es realizar una mejora o incorporación de nueva funcionalidad a nuestro sistema, con una gestión de vuelta atrás más segura dentro de los entornos productivos (o cualquier otro entorno crítico dentro de nuestra plataforma) en caso de que se produzca algún tipo de fallo dentro de la nueva entrega del aplicativo.

Para llevar a cabo dicha arquitectura, nos aprovecharemos de la capacidad de gestión centralizada de las políticas de enrutado en el ESB y de la reducción del “time to market” de los microservicios a la hora de generación de nuevas versiones.

 

canary-release-1

Una vez se dispone de la plataforma necesaria y de la nueva versión del aplicativo a desplegar, sería cuestión de desviar un porcentaje lo suficientemente significativo, desde el ESB a la nueva release del microservicio, de tal forma que se pueda testear y tengamos la seguridad de que esta nueva versión cumple todos los requisitos de calidad para ser la nueva versión estable.

 canary-release-2

En el caso de que se produjese algún fallo descontrolado en la nueva versión, sólo sería necesario volver a desviar el tráfico desde el ESB a la vieja versión y descartar o corregir la nueva.

Si por el contrario todo fuese bien, habría que terminar de desviar todo el tráfico a la nueva versión y considerar ésta como la nueva versión estable dentro de nuestra plataforma.

 

 canary-release-3

 

Conclusiones

Gracias al patrón de microservicios y a su rápida aceptación dentro del mundo empresarial, podemos ver cómo las arquitecturas SOA comienzan a desarrollarse más focalizadas en patrones de diseño escalables y mantenibles, adaptándose poco a poco a entornos tipo PaaS.

Por otro lado, los microservicios permiten aligerar de malas prácticas los flujos de orquestación dentro de las herramientas que implementan el patrón ESB lo cual, posiblemente, hará replantearse el modelo de negocio de algunos “vendor” de dichas herramientas a ESBs más ligeros para dar cabida a la nueva filosofía de arquitecturas de microservicios.

Para terminar, hay que reconocer que independientemente de la mala fama que se hayan ganado algunos patrones de diseño como ya se ha comentado con el ESB su utilización en función del problema a resolver, al igual que con el patrón de microservicios, debe ser estudiada y valorada, para realizar siempre la mejor aproximación que resuelva el problema en cuestión. Así que, recordad que cada problema es un mundo, que no todo es blanco o negro y que en la imaginación está el límite, así que usadla con moderación.

 

 

 

Elías Grande Rubio

Arquitecto SOA/BPM y Consultor de Seguridad TIC pragmático e investigador. Apasionado de la seguridad, las tecnologías middleware y de la computación de altas prestaciones. Diseñador de ideas revolucionarias que me hubieran hecho rico… pero las guardé en Megaupload y ahora escribo blogs.

Elías Grande Rubio ha escrito 7 entradas


Elías Grande Rubio

Arquitecto SOA/BPM y Consultor de Seguridad TIC pragmático e investigador. Apasionado de la seguridad, las tecnologías middleware y de la computación de altas prestaciones. Diseñador de ideas revolucionarias que me hubieran hecho rico… pero las guardé en Megaupload y ahora escribo blogs.

3 comentarios en “Microservicios y ESB, ¿amigos o enemigos?

  1. Muy interesante Elías. Estoy muy de acuerdo en que no todo es blanco o negro. Siempre he visto dos grandes problemas en el patrón ESB:
    1. De la misma forma en que las herramientas EAI pasaron de la noche a la mañana a llamarse ESB, el personal que típicamente implementa un ESB lo hace con la vieja mentalidad de “tiremos una interfaz” sin considerar temas mas propios del ESB como el fomento de la reutilización.
    2. Hay muchas implementaciones del patrón ESB.

    Juntando los dos puntos no es de extrañar que sea un término mucho más gastado en el mercado que el de microservicio o incluso el de APIs. Creo que los fabricantes de EAIs, que pasaron a fabricar ESBs, seran los futuros proveedores de API gateways, mediadores de microservicios o cualquier nuevo acrónimo que surja. Igualmente pasará con los implementadores.

    Lo que quiero decir con tanta verborrea es que creo que ambos patrones (3 si contamos los EAI) tienen su aplicabilidad y el éxito o fracaso depende en gran medida de utilizar el correcto con el personal adecuado. Ha habido muchos más fracasos con ESBs y servicios tradicionales que con los microservicios por un tema de volúmen de proyectos, aunque es verdad que localizar la responsabilidad en lugar de compartirla siempre es menos ruidoso ya que es un cambio menos impactante para la mentalidad monolítica que todavía hoy está muy presente.

  2. Pero si en un microservicio (que indicas que interactua con otros microservicios por REST) necesitas desarrollar una interfaz REST tenemos que el desarrollador ya necesita conocer sobre servidor web y REST no? Parecen aplicaciones pequeñitas que repiten codigo.

    No sería mejor usar una comunicación con otros microservicios basada en colas de mensajes tipo RabbitMQ? Pregunto. Le veo ventajas añadidas a esta forma de comunicarse y una escalabilidad sencilla al levantar instancias que se suscriben a tareas, pero sin necesidad de rodearlo de un servidor web e interfaz web. La unica pega es que tal vez algun micro servicio lo quieres exponer al exterior y vas a tener que crearle una capa REST, pero solo a ese.

    1. Realmente un microservicio expone un API, considerandose como API, cualquier opción más o menos estandarizada a nivel corporativo como puede ser publicar un servicio web SOAP/REST, suscribirse a una cola de mensajería en la que espera un mensaje de un formato concreto como si fuera un servicio SOAP/REST,…
      Obviamente, como bien dices, las aplicaciones no deben replicar código fuente, ya que eso sería una violación de los principios de la ingeniería del software. Si quieres leer más sobre el patrón de diseño de microservicios y cómo hay que utilizarlo de manera responsable para evitar la problemática que planteas de replicar código, te recomiendo el siguiente libro:
      – Arnon Rotem-Gal-Oz, “SOA Patterns”, September 2012, ISBN 9781933988269

      Por otro lado, en cuanto a la comunicación asíncrona basada en colas de mensajería, debes enteneder que cualquier patrón de diseño que se utilice durante el desarrollo de una arquitectura debe usarse con la certeza de que aplica al problema en concreto que se quiere resolver. Esto es así ya que aunque las arquitecturas SOA necesitan resolver problemas como por ejemplo, que en un entorno Cloud escalable necesites de “algo” que se encarge de realizarte enrutado dinámico, auto-descubrimiento/registro de servicios recien desplegado, circuitos de tolerancia a fallos en sistemas tolerantes a fallos,… las arquitecturas EDA (orientadas a eventos con colas de mensajería) tampoco se quedan atrás.
      Para realizar un servicio REST, a día de hoy, ya no necesitas de servidores web pesados ya que existen tecnologías como spring boot, python flask y otras muchas que te permiten crear servicios web tremendamente ligeros siguiendo el patrón de diseño de microservicios.
      Si quieres utilizar colas de mensajería, tendrás que valorar si realmente no necesitas orden a la hora de procesar tus mensajes para aprovechar al máximo todo lo que ofrecen las arquitecturas EDA, si necesitas un broker pesado de mensajería como puede ser RabbitMQ o Kafka, o simplemente necesitas utilizar agentes/actores de Akka para resolver ese caso en concreto.

      Saludos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *