¿Por qué un ESB ya no responde a la demanda del negocio?

En la primera parte, explicaré el origen de los ESB y las consecuencias derivadas de su adopción durante sus etapas iniciales en el mundo empresarial. En la segunda parte, continuaré con la evolución de las tendencias de integración con la llegada de las API y los microservicios, para posteriormente dar lugar a los enfoques de comunicación ligeros y distribuidos actuales.

Introducción

Viene siendo frecuente escuchar, como se señalan a los Buses Empresariales de Servicios (del inglés, Enterprise Service Bus -ESB) como desactualizados, anticuados y poco óptimos en contraposición con los enfoques ágiles y responsablemente diligenciados que permiten mantener una organización impoluta en entregar los datos de un destino a otro.

Esto, todos –o casi todos– los que trabajamos en la materia lo sabemos, pero lo que capaz algunos no hemos visualizado más allá de lo que nuestra miopía técnica nos permite ver; es que fuera del contexto de implementación de los llamados servicios, microservicios, API, eventos, colas, contenedores o mallas y las ventajas que proporcionan, existe un argumento bastante más simplistas que provocó que el enfoque centralizado de estos ESB, tuviese que evolucionar a otro que sí permitiese abarcar la demanda del negocio y de la exigencia real de las organizaciones: responder más rápido y a menor costo, lo que solicitaban los clientes.

Es bajo estos dos apelativos, “rapidez” y “costo”, los que enfatizaré este artículo para contar la vivencia que han tenido las organizaciones cuando se enfrentaban al reto de integrar sistemas entre sí, intentando no entrar en las minucias técnicas que, a nosotros los techies, nos gusta tanto mencionar.

Breve historia del nacimiento de los buses

En los años iniciales, cuando las organizaciones empezaban a abrazar la tecnología para sí mismos, hubo aquellas que, fruto de su prosperidad comercial, empezaron a necesitar que la data manejada en cada uno de sus departamentos pudiese ser accedida por otros –RRHH con Finanzas, Comercial con Marketing, Negocio con los clientes–. La solución inmediata consistió en desarrollar mecanismos de comunicación directos entre sistemas, lo que daría lugar al término de “conexiones punto a punto” (del inglés, point-to-point integrations).

Este enfoque involucraba que cada aplicación que interviniese en ese traspaso de datos debía ser modificado, aspecto que inicialmente estuvo bien pero, a medida que seguían creciendo las organizaciones y se necesitaban cruzar más sistemas entre sí, empezaron a originarse problemas en la gestión de estas conexiones: las personalizaciones propiciaban errores, se tornaron costosos los desarrollos, la búsqueda de personal cualificado para atender los desarrollos se volvió compleja –ya que había que entender los cambios que manos previas habían realizado–, provocando que los requerimientos se trabajasen cada vez más lentos.

Producto de este desorden de conexiones tipo “espagueti”, fue que empresas proveedoras de tecnología buscaron estandarizar estos enfoques de comunicación de manera que les permitiese agrupar y establecer el “cómo”, “por dónde” y “cuándo” debían conversar los sistemas entre sí. Esto dio como resultado la introducción de un centro de integración que propició las herramientas que simplificaron mucho la conectividad, permitiendo una cierta reutilización del trabajo de las integraciones realizadas.

De esta forma, podemos decir que los centros de integración fueron los precursores de los ESB; de hecho, fue de este enfoque que, junto con el avance de las tecnologías en los años venideros –inicios del 2000– sobre las formas de comunicación vía Internet (HTTP, XML, SOAP), se permitió no sólo identificar un sistema central que se encargaría de guardar dichas conexiones, sino que además lo haría a través de una forma de hablar común para todos. La aceptación y familiarización que empezó a tener esta visión, permitió definir algunas pautas para ser correctamente adoptada, lo que dio lugar a la Arquitectura Orientada a Servicios (del inglés, Service Oriented Architecture –SOA).

Con la estandarización del desarrollo de las comunicaciones entre sistemas, se logró rapidez y menor costo, ya que se empezaron a aprovechar las integraciones ubicadas en este único lugar para conectar más sistemas entre sí. Para SOA, las integraciones se denominaban “servicios” y el objetivo final era que las organizaciones dispusieran de un conjunto de servicios que exhibiesen tanto la data, como las funcionalidades de los sistemas. Dichos servicios serían reutilizables, lo que permitiría implementar nuevas aplicaciones sin la carga de un desarrollo profundo, ya que una vez que la integración se realizase por primera vez, se expondría como un servicio aprovechable para la siguiente aplicación.

La materialización de este enfoque dio lugar a los Buses Empresariales de Servicios, aquellos sistemas que permitían centralizar integraciones para comunicar sistemas consumidores (request) con sistemas proveedores (response) de datos, exponiendo dichas integraciones como servicios (vía web) para toda la empresa.

¿Y qué pasó después con los ESB?

A pesar de SOA y los ESB, los retos encontrados en algunas organizaciones con la adopción de estos enfoques fueron varios. La iniciativa de disponer de un gran sistema central organizador de la comunicación de otros sistemas resultaba atractiva: todos los gastos relacionados a la infraestructura (hardware y software) se financiarían una única vez y, debido a la complejidad del software, solo un único equipo dedicado de especialistas en integración sería necesario para realizar los desarrollos.

Al principio fue así, pero –y aquí el siempre inoportuno “pero”–, para cualquier empresa, coordinar una iniciativa transversal a todos los departamentos de la organización y asegurar que obtuviese una financiación continua –y que; además, dicha financiación fuese dirigida a servicios suficientemente aptos para ser reutilizables entre departamentos–, resulta ser una tarea muy compleja. Además, para aquellos tiempos, tanto los estándares de comunicación como las herramientas de implementación se encontraban madurando a la vez que se implementaban ESB, por lo que realmente los costos y tiempos de desarrollo de estos servicios, no eran bajos.

Si bien hubo organizaciones que lograron adoptar la adquisición de un ESB de forma exitosa, a menudo, las líneas de negocio esperaban un mayor ritmo de innovación en sus nuevas aplicaciones. Una vez más; al principio, disponer de varios servicios en un único sistema central permitía cumplir con las promesas declaradas, re-utilidad para responder más rápido al negocio. Pero, a medida que crecía la organización y por ende aumentaban los requerimientos, una vez más se volvía a complicar la operativa de implementación y soporte. Algunos de los retos fueron:

• Los cambios en servicios ya desarrollados podían desestabilizar las comunicaciones de otros sistemas, por lo que a menudo se necesitaba mucho tiempo en pruebas complejas.
• Debido al número de integraciones que alojaba un único sistema, los tiempos de ejecución –y, por ende, los tiempos de respuesta– se veían muchas veces impactados, lo que obligaba en invertir cada vez más en infraestructura.
• Así mismo, como la infraestructura que soportaba al sistema era centralizada, prácticamente era indeseable tener que reiniciar o detener los servidores que lo soportaban, lo que significaba todo un reto al equipo de operaciones al tener que implementar cambios “en caliente”, práctica propensa a errores.
• Las arquitecturas que permitiesen que la prestación del servicio fuese continua (alta disponibilidad) y la recuperación del entorno ante desastres, para estos sistemas, resultaban difíciles de crear. Normalmente conllevaba la adquisición de nuevos servidores, lo que aumentaba el costo de inversión.
• Las actualizaciones de los sistemas ESB a menudo eran arriesgadas, ya que podían perjudicar las integraciones existentes, lo que conllevaba a lidiar con varias versiones del mismo sistema en tiempo real.
• El mundo de las integraciones era; por aquel entonces, un campo muy complejo. Esta situación instigaba a las organizaciones menos maduras, a formar “equipos SOA” separados del resto de los desarrolladores, conllevándoles a cumplir con procedimientos estrictos para recibir los trabajos de forma secuencial –lo que se conoce como metodología cascada–, introduciendo dependencias separadas a cualquier proyecto de tecnología.
• No había herramientas de organización y registro de los servicios, lo que conllevaba a que la documentación se almacenara por separado y no se actualizase si ocurría algún cambio, volviéndola rápidamente obsoleta a no ser que estuviesen implantados procedimientos maduros de actualización de la documentación en los equipos.
• Y si no se documentaba, se requería de un traspaso de conocimientos de persona-a-persona, lo que impedía cumplir con la promesa de reutilización de servicios.

El resultado de implementar los ESB en las organizaciones fue que los equipos SOA se convirtieron en verdaderos cuellos de botella, siendo justamente lo contrario a lo que pregonaba esta adopción tecnológica, convertirse en habilitadores que permitiesen la armonía y rápida respuesta de comunicación entre todos.

Miras a una nueva era de integración

La llegada de los buses de servicios al mundo empresarial, resultó ser la primera apuesta en las organizaciones para verdaderamente dedicar tiempo e inversión en un concepto que, con el transcurso de los años, fue adquiriendo cada vez mayor relevancia a medida que iban evolucionando las propias tecnologías que permitiesen adoptar estos conceptos de una manera más óptima (o al menos, más sencilla para todos).

Los ESB no fueron la solución final de comunicación entre sistemas, como ya hemos podido visualizar con el listado de retos que encontraron los equipos de trabajo con su adopción; pero sin lugar a dudas, fueron los impulsores que permitieron ahondar aún más la investigación sobre un campo todavía muy verde en materia de interconexión entre componentes, lo que permitió situar el concepto de integración como un aspecto tecnológico único y necesario en cualquier organización con miras de crecimiento y, bien llamado, transformación digital.

En el siguiente artículo, hablaré de cómo la tendencia en integración pasó de un enfoque de adopción “empresarial” a uno de “aplicación” y de “negocio”, permitiendo de esta manera dar origen a otras líneas de tecnología que, con el mismo objetivo inicial que se buscaba con los ESB, ofrecieron una gestión adecuada y rápida de las formas de comunicar sistemas con otros.

Agradecimientos

Gracias especiales a las opiniones y contribución en la revisión de este artículo a: Marcos Gómez, Rodrigo García, Carlos Arias, Ernesto Sánchez y Adrián Campos. SOAInt España.