Mitos y realidades del Middleware en la era post digital

En la primera parte de este post, te contamos cómo se había trasnformado el Middleware en la era post digital. Con esta segunda entrega te contamos cuáles son los mitos del Middleware y qué realidades abarca.

Desde SOAINT hemos encontrado que en el mercado tecnológico se escuchan diferentes visiones sobre el rol del middleware la actualidad. Con base en nuestra experiencia podemos realizar las siguientes consideraciones:

¿Mito o realidad? El Middleware ya no tiene cabida y es obsoleto en la era digital y post digital

Mito. Por el contrario, son parte de un Middleware, el desarrollo nativo para Cloud, la gestión de API y su ciclo de vida, la generación de ecosistemas tecnológicos entre partners o socios de negocio. Considerando que el Middleware integra datos y eventos entre aplicaciones, en la era post-digital llena de dispositivos:

• IoT
• Serverless
• Funciones
• RPA
• ML

Cobra más importancia que en el pasado donde las integraciones de datos en algunas industrias eran más introspectivas y menos abiertas.

Un Middleware con enfoque SOA / BPM, es rígido, poco flexible y ágil para el mundo cambiante de hoy

Realidad. Es necesario replantear las estrategias de integración tradicionalmente basadas en SOA para que ahora respondan a un ecosistema de TI. Todos ellos basados en DevOps, contenedores, desarrollos orientados a REST, microservicios, Service Mesh…

Hoy todo está más distribuido, y es necesario que las integraciones también se comporten ágiles y orientadas a Cloud. En el caso puntual de las automatizaciones vía BPM, la modernidad trae consigo el enfoque de Citizen Developer bajo el paradigma low-code y no-code.

En este sentido, y con las evoluciones de las suite BPM (BPMS) hacia un enfoque pragmático y amigable para usuarios de negocio, además de la práctica metódica de BPM en sí misma, la aplicabilidad de este enfoque persiste e incluso, con la orientación a producto, agilidad al negocio y otras estrategias de la era digital, es aún más protagónica en las empresas.

El ESB ya no sirve. Ahora todo es microservicios y API

Mito. Hay capacidades del ESB que siguen siendo relevantes en los escenarios de integración modernos de los clientes como la orquestación, la transformación de mensajes, el procesamiento batch o por fichero, la compensación de transacciones, entre otros.

El patrón ESB sigue vigente como la capa de Servicios que soporta a una capa de API en escenario de mediación, y ahora, se complementa con enfoques como Event-Driven Architecture y Mensajería avanzada o distribuida para eventos asíncronos. Hoy por hoy, el concepto ESB es útil, pero no suficiente, y evoluciona a una plataforma de integración híbrida y distribuida. Además, mantiene capacidades como mediación, orquestación y transformación, y establecen patrones de diseño y desarrollo para API, Service Mesh y EDA.

Los microservicios en una arquitectura de aplicación son el Middleware de la empresa

Mito. Un microservicio es independiente y es capaz de ejecutar su propio ciclo de control sin depender de un tercero. Un microservicio bien diseñado no debe hacer la veces de middleware. Lo que suele ocurrir es que, al no poder desacoplar funciones del core o de los legados, los microservicios terminan “mediando”, pero para mantenerse fiel a sus principios, no debieran haber estas dependencias y solo debería ser una arquitectura de transición si es que se presenta el caso.

Una forma de mitigar esa relación es utilizar una integración asíncrona (por eventos) entre el microservicio y el sistema core/legado. Hay que cuidar que los desarrollos tengan una vista ampliada al negocio más que a los límites de una aplicación, con el fin de que sean reusables y conectables a través del Middleware, con otras arquitecturas o ecosistemas de la empresa, sea interno o externo. Así es como se asocian los patrones como DDD (domain-driven design) o CDD (capability-driven design).

El Middleware es solo integración de datos y tuberías, sea de aplicación o de todo el ecosistema de tecnología

Mito. El Middleware por principio automatiza al negocio. Y cualquier iniciativa de escala empresarial que incorpore este principio podría considerarse como parte del Middleware. Por ejemplo: sistemas de decisión o reglas de negocio, automatización de procesos, servicios de integración.

¿Quieres más información sobre el Middleware y cómo integrarlo en tu negocio? ¡Contacta con nosotros!

Autores: Carlos Andrés Arias y Gabriel Layerenza.