headstone-312540_640

Me encuentro con este artículo de Kai Wähner sobre la papel de ESB en una arquitectura con microservicios que llama mi atención. Evidentemente, el tema de los microservicios está de moda en los “ambientes”, y una de las cosas que quiero saber es como encaja esta forma de diseñar el software con SOA (si es que encaja de alguna manera).

Como en casi todo, hay opiniones para todos los gustos. La mía es que si dejamos a un lado la tradicional implementación de SOA (basados en web services tipo SOAP) y aplicamos únicamente los 8 principios de Thomas Erl y sus colegas, los microservicios deben verse como una implementación más de SOA.

Por supuesto, hay algunas “fricciones” entre los conceptos que hemos manejados hasta ahora y los propugnados por gurús como Martin Fowler. Y uno de los primeros que me llamó la atención es este “endpoints inteligentes y tuberías tontas”.

¿Quién es el tonto de la película?

En el artículo, Fowler dice que las “tuberías”, es decir, lo que se entiende que hace el Bus (el enrutado de mensajes) deben ser tontas. La inteligencia debe estar en los servicios (en los endpoints).

Sobre este particular, yo tengo el corazón partío (como diría el poeta). Creo entender las ventajas de hacerlo como dice Martin (que en la práctica prescinde del ESB) pero también entiendo que el uso de una tubería inteligente (el ESB) tiene varias ventajas:

  1. Los servicios pueden ocuparse únicamente de la lógica de negocio, no de la lógica de integración. Esto da como resultado que los servicios son más sencillos de implementar y de mantener.
  2. Se supone que los servicios deben ser agnósticos. Es decir, que se pueden reutilizar lo máximo posible en varios contextos (digamos que en varios servicios compuestos a lo largo de la empresa). Si la lógica de integración la hace el propio servicio ¿no serían estos menos reutilizables?

Por otra parte, creo también que el ESB (la tubería inteligente) debería ser lo más simple posible. Cada vez soy más de la opinión que mucha veces usamos unos auténticos monstruos como ESB (me refiero a las suites de los principales fabricantes) cuando en realidad nos sirve con uno mucho más sencillo o con un simple framework de integración (como Spring Integration o Apache Camel).

En definitiva, en mi particular “arquitectura soñada”, yo utilizaría una solución sencilla de integración (como un framework de integración) y no dejaría toda la inteligencia de la integración dentro de los servicios.

Volviendo al artículo de Kai, lo primero que hace mención es precisamente que se ha abusado de la marca “ESB” por parte de los grandes fabricantes y consultoras, convirtiéndolo más en una producto de marketing que tecnológico. Viene de a decir que agotados los anteriores “productos” como el Enterprise Application Integration (EAI) había que inventarse un nuevo concepto para seguir vendiendo. No le falta razón.

Siguiendo con las opiniones del artículo, dice que el ESB no está muerto. Es necesario simplemente por lo mucho que aporta:

  • integración
  • orquestación
  • enrutado
  • procesamiento de eventos
  • correlación de mensajes
  • monitorización de negocio

Tengo que remarcar que el término ESB hay que entenderlo como un patrón de diseño, con muchas implementaciones que podemos usar, más que un producto concreto.

Kai describe 6 desafíos que tienen que afrontar los microservicios. Son conceptos a los que estamos acostumbrados a tratar en SOA, pero que los microservicios ponen en tela de juicio ¿son realmente necesarios? ahí va mi opinión:

Contratos de servicios

El contrato de los servicios es una de las primeras cosas que ya estaban resueltas en los web services SOAP. Tenemos una definición de contrato basado en WSDL que describe perfectamente los parámetros de entrada y salida y las operaciones que hace el servicio en cuestión.

El WSDL por supuesto no es ninguna maravilla y es bastante complejo de entender pero ahí está. Un contrato que puede ser analizado por herramientas de manera automática, que no es ambiguo (hasta cierto punto) y que cumple con su cometido.

Con los servicios REST, los microservicios se suelen hacer así, no tenemos un contrato estándar como el WSDL. Hay algunos intentos como el WADL, pero en la práctica creo que se usa bastante poco.

Ya sé que en teoría un servicio REST se puede autodescribir (ver HATEOAS), pero en la práctica lo que más he visto para la descripción del contrato es el clásico documento de texto con algunos mensajes de ejemplo.

¿Hemos perdido en este caso al pasar de SOAP a REST? yo creo que sí.

Exponer microservicios desde aplicaciones existentes

¿Qué sucede con las aplicaciones ya existentes? sobre todo las implementadas en lenguajes como COBOL o PL/SQL. Estaremos de acuerdo que estos lenguajes o plataformas no son muy amigables respecto a exponer sus lógicas como servicios sobre HTTP.

En teoría un ESB comercial incorpora “conectores” que de manera declarativa, sin programar, pueden exponer una transacción COBOL o un procedimiento PL como servicio. Y digo en teoría porque yo al menos no he visto ningún ESB que funcione bien en este caso. Pero si es así (podríamos implementar un conector ad-hoc), ¿no se justificaría el uso de un ESB para la exposición “automática” de lógicas legacy.

Descubrimiento de servicios

Soy tremendamente escéptico respecto a las bondades de los Registry o Inventario de servicios en runtime que ofrecen los grandes productos. En teoría, en tiempo de ejecución un servicio o aplicación podría preguntar al registry por tal o cual servicio (con unos criterios de selección) y automáticamente devolver un endpoint con el servicio más adecuado. Tampoco he visto nunca esto funcionar, la verdad.

Al final, un registro se reduce en la práctica a una tabla con unos campos para seleccionar en en la consulta y un endpoint como resultado. Nada sofisticado, pero sin embargo necesario para desacoplar el cliente del servicio (como dicen los principios de SOA).

Aquí sí que creo que aporta bastante el concepto de HATEOAS en REST. Es decir, la respuesta de un servicio me da “pistas” en forma de links a otros servicios relacionados. Así por ejemplo, podría partir de un servicio que me devuelva la información de un cliente, y este devolver en el mensaje un link al servicio de consulta de dirección de ese cliente, otro a la consulta de productos contratados, etc. etc. Me parece un concepto tremendamente sencillo y muy potente.

Coordinación entre servicios

También aquí soy un poco incrédulo sobre las herramientas de productividad que dan las suites de integración para la creación de servicios compuestos. Se supone que únicamente con el ratón se pueden hacer maravillas pero mi experiencia es que muchas veces es más fácil hacer esto tirando líneas de código que con la dichosa herramienta.

En fin, que aquí sí que creo que no echaría de menos las herramientas que dan los ESB comerciales. Yo seguiría llamándoles “integraciones” pero quizás las implementaría con un programa normal y corriente y/o con las facilidades que pueden dar los frameworks de integración.

Gestión de despliegues complejos y su escalabilidad

Yo aquí, y al día de hoy, prefiero la visión que proporcionan los microservicios. En lugar de un servidor centralizado (el bus) donde se despliegan las lógicas de integración, me gustaría que estas lógicas estuvieran implementadas de manera desacoplada y que fuese posible su manera desacoplada del resto.

Sólo así podremos lidiar con los despliegues complejos, mejorar la escalabilidad y sobre todo el mantenimiento.

Visibilidad a través de los servicios

Sobre la gestión de eventos en tiempo real, al menos aplicaciones de negocio que suelo ver, no he visto esta necesidad más allá de algunas implementaciones de soluciones de chat.

Sin embargo, creo que tienen mucho potencial por delante a medida de que los “aparatos” y aplicaciones que pueden generar estos eventos incrementen su número por cientos de miles y millones (smartphones, coches, wearables, domótica, etc. etc.)

Conclusión

En definitiva, y como casi en todos los casos donde se afirma que tal o cual cosa en SOA, yo diría más bien que el ESB no estaba muerto, estaba de parranda ;), o lo que es lo mismo, los conceptos que justifican el patrón de Bus siguen estando vigentes y que quizás hemos fallado en el uso de un producto y en su implementación.