Cinco años han pasado desde esta entrada en mi blog «¿es necesario un ESB en SOA en todos los casos?» y obviamente cinco años en este mundillo son muchos años, como para que hayan cambiando unas cuantas cosas.
A día de hoy, todavía hay una discusión abierta en muchas empresas sobre la conveniencia o no de basar su arquitectura en un producto ESB, o usar algo más ligero desde hacerlo simplemente con un lenguaje de programación como Java con un framework tipo Spring, o con el añadido de un framework con capacidades de integración como puede ser Spring Integration o Apache Camel.
Ventajas de un producto comercial tipo ESB
Las ventajas son múltiples, como no podía ser de otra forma en un producto que está precisamente pensado para implementar y configurar servicios.
- Estandarización del desarrollo: todos los servicios se hacen con las mismas herramientas y de la misma manera
- Centralización del control: la plataforma se puede manejar desde un sólo punto (consola). Aspectos como la configuración, despliegue, retirada de los servicios y en definitiva el control de todo el ciclo de vida del servicio se puede hacer desde aquí.
- Monitorización: se puede saber qué esta pasando con los servicios, cuantas veces se ejecutan, tiempos de respuesta, ratios de reutilización, etc. etc.
- Editor gráfico para la implementación del servicio.
- Es posible definir políticas como las de seguridad de manera desacoplada de los servicios, es decir, se pueden hacer los servicios sin seguridad y después mediante configuración, aplicar esta política sobre los servicios. Por supuesto, las políticas las pueden realizar otro rol diferente al rol del constructor de los servicios.
- Soporte del fabricante. En el caso de que algo vaya mal y aparezca un bug en el producto, tenemos a alguien a quien acudir para arreglarlo y nos pasará un parche para arreglar el producto. Esto es especialmente apreciado en las grandes empresas, en las que se quiere jugar sobre seguro con esto.
Inconvenientes
Pero también veo varios problemas en la utilización de un producto comercial tipo ESB:
- Por ser un producto comercial de un fabricante utiliza tecnología propietaria. Es decir, como norma general, todo lo que se desarrolle sobre esta plataforma, en la que se aprovechan las facilidades que ofrecen, únicamente se puede ejecutar sobre esta plataforma.
Esto produce obviamente lo que se denomina vendor lockin respecto al fabricante, o dicho en otras palabras, vamos a estar cautivos de este fabricante. - Encontrar a personal cualificado que sepa utilizar realmente el producto, en muchas ocasiones, puede ser de gran dificultad. Y quizás, cuanto más caro y más avanzado o con más funcionalidades tenga el producto, más difícil será encontrar a este personal, simplemente por una cuestión de números. Cuando más exclusivo sea la herramienta, menos gente habrá que sepa utilizarla, y por motivos de esta escasez, más caros serán estos especialistas.
- Coste de las licencias. Este tipo de productos no suele ser precisamente barato. Se necesita ser una gran empresa, con muchos servicios que desarrollar y gestionar para compensar el gasto.
Aparte de esto, parece que las tendencias en el diseño de servicios, se están apartando del concepto de tuberías inteligentes, donde el trabajo de de integración y encaminamiento no lo hace el propio servicio si no el middleware (el bus) a otro concepto en el que que los servicios son inteligentes y las tuberías tontas, donde el trabajo duro lo hace el propio servicio haciendo que el papel del bus pierda sentido.
Alternativas
En mi opinión, tenemos alternativas al uso de un producto comercial de ESB que a la larga nos puede resultar más ventajoso. Me estoy refiriendo a utilizar un framework de desarrollo como Spring, al que podemos añadir la extensión de Spring Integration en el caso de que necesitemos conectores específicos para acceder a lógicas de negocio mediante protocolos que no sean el típico HTTP como colas de mensajería.
La idea en este caso es utilizar un framework muy conocido en el mercado, cuya licencia es gratis, y que se puede utilizar en cualquier infraestructura con un mínimo esfuerzo.
Por supuesto, tendremos que hacer frente a algunos aspectos por nuestra propia cuenta, como el soporte del producto (tendremos que utilizar los foros de la comunidad en lugar de acudir a un soporte oficial seguramente). También tendemos que hacer las cosas a más bajo nivel, como asegurarse de la monitorización, de la aplicación de políticas en los servicios, etc. etc.
A pesar de todos los inconvenientes, creo que las ventajas lo superan, empezando porque tendremos un código que es «nuestro», que podemos ejecutar si tener que pagar licencia y que no tendremos prácticamente el temido vendor locking que comentaba anteriormente.
En definitiva, un bonito debate ¿no crees?
Blog de Andrés Hevia 
06/03/2016 at 19:47
Desde mi punto de vista es correcto existe mucho debate y profesionales que están a favor y en contra actualmente de ESB, particularmente yo sigo a favor, independientemente de que si el ESB sea o no propietario, pienso que los puntos positivos que brinda el ESB a los proyecto Middleware son más favorables que los negativos. Temas con segmentación de dependencias, eliminación de punto a punto, seguridad, mediación, todo que esté centralizado por el BUS. liberando a los servicios de estos temas para mi es muy importante para dejarlo del lado.
06/03/2016 at 19:48
Uff, nuevamente un tema muy complejo y donde creo que el principal problema son los términos. ESB… ¿A que nos referimos con un ESB? ¿Lo que hace 10 años las empresas de software de integración vendían? ¿El software que actúa como Middleware a día de hoy?
El principal problema que veo en el artículo es juntar ESB que es una tecnología, un componente, una caja, con un producto y es más, con un producto comercial bastante concreto. Parece que más de ESB estamos hablando de SoftwareAG Integration Server, o Websphere ESB / IBM Integration Manager, TIBCO BW, etc etc etc.
Y se antepone a cosas como Camel o Spring Integration. ¿Acaso no es Camel un ESB igual que los anteriores? ¿Por qué no? ¿Por que no tiene un editor gráfico? Bueno, ahí tienes RedHat FUSE. Es FUSE un «ESB» como se refiere el articulo y no lo es «Camel» que comparten el mismo core?
Igualmente el hecho de hablar de integraciones como tuberías inteligentes en un modelo propio de un EAI más que de cualquier software de integración más orientado a Servicios, es algo que es de por si antiguo, ya que quien más quien menos desde el punto de vista empresarial en los últimos 5-10 años ha evolucionado sus productos de integración en esa línea, y mucho más con el auge de las arquitecturas orientadas a Microservicios. Si bien es ciertos que excepciones como IBM Integration Bus siguen con el modelo «orientado a flujo» la mayoría de soluciones y hablo de: TIBCO BW, Oracle Service Bus, WSO2 ESB, Mule ESB, tienen un enfoque orientado a servicios desde hace años. Si bien queremos llamar ESB a lo que antes era un EAI y considerar que los nuevos productos de integración no son ESB sino que son otra cosa (llamemosles «Service Distributed Platform» o algo así) pues podemos estar de acuerdo.
Pese a eso e incluso yendo a las ventajas y desventajas una a una, me surgen los siguientes comentarios:
Ventajas:
1.- La estándarización se tiene igual con Spring / Camel que con un ESB comercial. El uso de cualquier framework también «coarta» esa libertad. Pero si nos vamos a un enfoque microservicios, donde tenemos un paradigma «multi-lenguaje», se nos cae la estándarización en ambos casos. ¿Es la estandarización algo propio de los ESB?
2, 3 .- De acuerdo, pero no es nada propio de un ESB comercial, es algo propio de cualquier plataforma. Es algo que también vas a tener usando los frameworks de integración que comentas, pero a otro nivel. ¿Servidor de aplicaciones?¿Contenedores? Siempre vas a necesitar un control de lo que estás desplegando con la granularidad que requieras.
4.- Nada que añadir.
5.- Nuevamente, nada propio de los «ESB comerciales». Sin ir más lejos, Spring Security ofrece politicas declarativas y mil frameworks más cubren el gap.
6.- De un tiempo a esta parte, empiezo a creer más en un soporte de la comunidad que en uno comercial, cuando pueden «dejar de soportarlo» cuando ellos consideren oportuno o cuando hay una versión posterior a la cual no has actualizado.
Desventajas:
1.- Sin duda hay un vendor locking, pero mucha de esas tecnologías propietarias se basan en estándares abiertos como SCA u OSGi, no dejan de ser más propietarios ni ser más vendor locking que Spring. ¿Acaso unos flujos de Camel los puedo ejecutar sobre Spring Integration?
2.- 100% de acuerdo
3.- 100% de acuerdo si hablamos de «ESB propietario» pero hay ESB’s que cumplen con los mismos principios que indicas y son Open Sources o Freeware al menos. Ejemplos serían WSO2 ESB o Mule ESB.
Yo creo que el principal problema es el nombre: ESB, es lo que genera problemas, porque en tecnología lo primero que se queda viejo son los términos. Pero realmente los «ESB» han sufrido una evolución tan grande en los últimos años que a día de hoy no se pueden comparar con sus primeras versiones y se están convirtiendo más en Plataformas de ejecución de servicios que en ejecutores de flujos como anteriormente.
Te recomiendo encarecidamente este post y su presentacion de Kai Wähner: https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/, que trata también ese tema conjuntamente con el auge del enfoque a Microservicios.
Como siempre, un placer leerte y poder dialogar sobre estos temas :).
Un saludo,
06/03/2016 at 19:53
Gracias a ti por tu comentario, esto si que es mejorar el blog.
Es un tema interesante en el que un simple post se queda corto, habrá que continuar con el tema.
07/03/2016 at 13:55
Tema Complejo por lo de las herramientas propietarias y quien puede pagar y quien no , que empresas pueden acceder a la tecnología y quienes no, sin embargo hay opciones como Mule que podrían emular en varios aspectos el uso de bus propietario , pienso y me disculpan , la herramientas propietarias son para corporaciones que pueden pagar por ellas y ven en el.pago de una licencia una buena inversión para gestionar mejor su plataforma IT , en cambio empresas que desean sólo acceder a software libre sin medir que a la larga tienes que invertir horas de investigación en como hacer una determinada tarea , sobre el código fuente , creo se hace muchas veces por protegeralgo que en oportunidades no es el Core de tu negocio , si usas herramientas libres o propietarias , que puedes hacer que no se pueda conseguir seguir en la red o en día o pagar por clonar cualquier pieza de software y adaptarla a nuestros requerimientos , pienso que se debe hacer esfuerzo mejor por proteger por ejemplo los datos de nuestros clientes y es en muchas empresas lo que.menos se ocupan y son los clientes quienes generan las ganancias.
24/05/2016 at 20:42
Hola me parece bueno el análisis, pero creo que mencionar Spring Framework es de igual manera cerrar el campo de las posibilidades, cada día es más complicado administrar un proyecto Spring con tantas y tantas configuraciones a lo cual empiezo a ver mas poderosas algunas soluciones de IBM para resolver proyectos de gran escala.
Saludos