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.

esb

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.

Anuncios