Durante años, en las arquitecturas orientadas a servicios, siempre se ha definido en sus diferentes implementaciones un elemento central que le daba sentido prácticamente a todo: el Enterprise Service Bus o ESB para los amigos.
Aunque realmente, en lugar de un producto habría que considerar el ESB como un patrón de diseño con varias e importantísimas características como transformación del protocolo de comunicación, transformación de los mensajes, enrutamiento, mediación, etc. etc.
En el mundo del bus los servicios son bastante tontos, únicamente conocen su lógica de negocio pero nada más, es como si fueran ignorantes de lo que les rodea… cosa que no está mal si tenemos en cuenta el principio de desacoplamiento. Podríamos decir (y el término no es mío) que en este escenario los servicios son «tontos» mientras que las tuberías son listas. La inteligencia del sistema reside en el ESB, él sabe qué hacer en cada momento, qué es lo que hay que hacer con un mensaje y adonde hay que redirigirlo y cómo transformarlo… es tan listo que con frecuencia se utiliza para desplegar en él lógicas de negocio.
Hasta aquí todo bien, sin embargo, si lo volvemos a mirar con un ojo crítico vemos que existen algunas desventajas que vienen aparejadas a este tipo de Middleware. En primer lugar, cada fabricante tiene el suyo que se configura y programa de manera diferente. Es cierto también que ha habido algunos intentos de estandarizar el desarrollo pero creo que no ha cuajado lo suficiente… al final nos encontramos cautivos del fabricante del Bus, podríamos decir que si depositas tu lógica en unos de estos bus tendrás que seguir con él (para bien o para mal) por unos cuantos años.
En segundo lugar, un bus es un lugar centralizado donde se despliegan las mediaciones (servicios compuestos), políticas de seguridad, etc. etc. Esto nos proporciona un único punto de acceso y un único punto de control… lo cual también está muy bien por un lado. Pero por otro lado dependemos en exceso de único punto de fallo y de gestión. ¿Alguna vez has tratado de desplegar decenas de mediaciones en un Bus? No es una tarea gratificante precisamente, aunque sea únicamente por la labor de coordinación y el trabajo que eso supone.
Los microservicios nos hacen replantearnos todo
Con una orientación a microservicios, ¿qué sucede con el ESB?. Precisamente en un escenario donde lo que se quiere es la independencia de despliegue y ejecución de los servicios, tener un punto centralizado no es lo mejor.
Citando al maestro Martin Fowler precisamente se busca una aproximación alternativa: endpoints inteligentes y tuberías tontas.
¿Necesitan los microservicios un ESB? la respuesta es obviamente no. O bien los microservicios son «reinos independientes» que se coordinan ellos mismos mediante protocolos ligeros como HTTP o como mucho van a necesitar una infraestructura muy ligera como pueden ser cualquier implementación de colas.
Conclusión
Así pues, ¿está el ESB obsoleto? En mi opinión, si tu enfoque son los servicios independientes (microservicios o no), sí que lo está.
Por supuesto no lo están los conceptos que trata de obtener, como el control y la seguridad. Pero habrá que implementarla de otra manera, incluso de una manera más compleja y difícil de llevar a la práctica. Nadie dijo que los microservicios fuesen fáciles de hacer.
Blog de Andrés Hevia 
05/02/2017 at 22:06
Buenas Andrés,
Un buen articulo pero discrepo bastante con las conclusiones que se vierten, creo que se centra excesivamente en los ESB tradicionales, de los años 2000, en lugar de las plataformas de integración que ahora mismo tenemos.
Pesar en un ESB como en EAI de interconexión de extremos como podría ser el MQ Message Broker de IBM, TIBCO Integration Manager, cumple lo que dices, pero obviamente estamos hablando de productos de 15 – 20 años de antiguedad.
Hoy siguen existiendo los ESB, entendidos como plataformas de integración, que para nada son centralizadas ni soportan la frase de «único punto de fallo». Es como si dijésemos que un PaaS es un elementro central y único punto de fallo porque los servicios corren sobre el. Esto precisamente no es correcto.
Los microservicios replantean todo, pero no entiendo porqué intentamos verlo siempre desde el punto de la integración, cuando el microservicio lo que rompe es el backend, no el elemento mediador. Y sin embargo tendemos a pensar que el microservicio es como servicios SOA pequeños, y no es sólo eso. Sino que el microservicio mata al backend tradicional, por lo que su idoneidad con un ESB o plataforma de integración moderna es más que clara y necesaria.
Aunque sólo sea para cubrir temas como orquestaciones o demás. Precisamente estamos viendo en los últimos meses a Netflix, lider incuestionable de microservicios lanzar capas de orquestacion para cubrir estas necesidades.
El ESB no esta ni muchisimo menos muerto, pero obviamente es un concepto que ha evolucionado muchisimo en los últimos años para adaptarse a las nuevas necesidades.
A ver si escribes más a menudo que se agradecen este tipo de post en castellano 🙂
05/02/2017 at 22:22
Gracias por el comentario 😉 está bien que haya debate.
Lo de que dices que los ESB de hace 15 años, quizás sea así, pero me temo que este tipo de ESB son los que hay ahora en muchas empresas actualmente.
Por lo de único punto de fallo no me refería tanto aunque puede caerse y tener una pérdida del servicio como el hecho de poner todos los huevos en la misma cesta. Yo he visto que un despliegue tardaba varias horas porque hacía que desplegar varias mediaciones en el bus y había que hacerlo de manera secuencial..
Creo que el desarrollo hay que hacerlo en java, js o en el lenguaje y entorno que más convenga, no en el bus, con su vendor lock-in que nos hará cautivos de un fabricante durante años… A eso me refería…
06/02/2017 at 10:07
Diferencias importantes entre SOA/MS que merecería la pena comentar:
https://www.linkedin.com/pulse/soams-service-oriented-architecture-microservices-jose-negreira-lopez