integration

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.

  1. Estandarización del desarrollo: todos los servicios se hacen con las mismas herramientas y de la misma manera
  2. 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í.
  3. Monitorización: se puede saber qué esta pasando con los servicios, cuantas veces se ejecutan, tiempos de respuesta, ratios de reutilización, etc. etc.
  4. Editor gráfico para la implementación del servicio.
  5. 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.
  6. 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:

  1. 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.
  2. 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.
  3. 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 inteligentesdonde 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?

 

 

 

Anuncios