Modernización Middleware: ¿migrar integraciones?

Desde principios de los años 2000, cuando comenzamos a hacer integración empresarial, hablamos sobre los muchos patrones de integración (síncronos y asíncronos, VETRO, procesos Batch y muchos otros). Principalmente el patrón ESB. El bus de servicio empresarial, esa mágica caja negra con todos sus conectores, que simplemente se podía “Instalar, enchufar y configurar”. Hacía que la integración de un sistema a otro fuera un objetivo simple de lograr. Todo ello afecta al Middleware.

Entre los factores importantes que influyen en la modernización del Middleware se encuentra:

• La nube, la escala web
• Interactuar con nuevos tipos de usuarios
• IoT, experiencias en tiempo real
• Serverless y experiencias de la vida real con Integración empresarial.

Y a partir de ese enfoque un tanto teórico, obtuvimos productos ESB reales, herramientas que cumplían esa función de conectar cualquiera sistema. No siempre tan mágicamente como sugiere la teoría, pero, aun así, la mayoría de las veces lo hicimos funcionar. Con frecuencia se basa en servicios web basados ​​en XML y SOAP + WS = * y con productos complejos que se ejecutan en servidores de aplicaciones masivos. En mi caso particular con la tecnología IBM y su reconocido message Broker como un ESB advanced por sus características de EAI (Enterprise Application Integration) (Desde las versiones que Dependía de DB2, Configuration Manager y MQ, hasta la versión actual de AppConnect(v11)); también productos similares tenemos disponibles en ORACLE, Microsoft, Tibco, SAP, WSO2, MuleSoft y otros. EL ESB es quien nos proporciona una capa de Abstracción. SOA fue el estilo de arquitectura que adoptamos, con el desacoplamiento como su bastión principal y principios importantes como la encapsulación, la autonomía, la abstracción, la reutilización y un contrato de servicio estandarizado.

Y con la plataforma de integración, casi cualquier flujo de datos parecía un desafío que podíamos resolver. La capacidad de implementar rápidamente una integración desde un origen “A” a un destino “B”, a través de nuestro producto ESB nos atrajo a implementar muchos tipos diferentes de flujos con esta plataforma.

Nuestro martillo golpeó una y otra vez. Desde “la interfaz de usuario simple que necesita algún elemento de datos de una base de datos como backend” hasta “los documentos que debemos alojar en un sitio FTP/SFTP y deben almacenarse en nuestro gestor Documental”, cualquier flecha que en un diagrama une dos bloques, se convertía en un problema a resolver con el ESB.

Con esta forma de pensar y trabajar, hemos logrado mucho. Pensamos en términos de metadatos comunes y estandarizados y modelos canónicos en todas las empresas, por ejemplo, lo que a su vez es una piedra angular para el diseño impulsado por dominios, lo que nos inspira a los microservicios. Y lograr el desacoplamiento entre sistemas y una forma estructurada de abordar los flujos de datos.

Sin embargo, en muchos casos, las plataformas ESB se volvieron muy pesadas. Debido a los muchos servicios y flujos diferentes que se ejecutaban en él y las muchas instancias de todos ellos que tenían que ser procesados. Y la cantidad de recursos que requieren.

El desacoplamiento lógico que logramos entre los servicios y su consumidor no se correspondió con el desacoplamiento físico: en general, el producto de integración tenía que hacer todas las integraciones de un conjunto compartido de recursos físicos y el tráfico intenso en un flujo de integración afectaba a los demás. Además, la gestión de estas plataformas complejas y con sobrepeso se ha convertido en un problema a mantener. Desde la aplicación de parches y la actualización de la plataforma, pasando por el despliegue de servicios nuevos o modificados, hasta el escalado bajo peak de carga, el monitoreo, la gestión de errores, el logro de la estabilidad a largo plazo y por consecuencia el rendimiento necesario, se ha vuelto muy difícil gestionar la plataforma de integración de todo tipo.

Un nuevo mundo en integración

Con el aumento a toda escala, debido a las altas demandas de soluciones en tiempo real y de escala web introducidas por el IoT y un mayor crecimiento del uso de aplicaciones, los requisitos de seguridad más estrictos, el ciclo de cambio más rápido, el aumento del uso de aplicaciones estándar (principalmente SaaS) y la llegada de la nube, que inspiró nuevos patrones de arquitectura y perspectivas como el diseño impulsado por el dominio, los microservicios, los CQRS(Command Query Responsability Segregation), los generadores de eventos, combinados con los avances en la tecnología, por ejemplo, contenedores, ServerLess, REST, tecnología API, el mundo ha cambiado. Sobre la base de la experiencia y los nuevos conceptos que han demostrado su valor y aprovechando las nuevas ideas y tecnologías, nos estamos moviendo hacia nuevas formas de abordar diferentes tipos de flujo de datos. Lo más probable que sigamos llamándolos Integración, pero reconocemos que son muy diferentes y que deben aplicarse de formas muy distintas. Renunciamos a nuestro martillo y lo sustituimos por un conjunto de herramientas más variado.

Integración Vertical

Flujo de datos que tiende a ejecutarse con grandes volúmenes, por lo que debe ser muy escalable, debe completarse con bastante rapidez (no más de 200 ms) y su implementación suele ser no sólo sin estado(stateless), sino relativamente simple. el API Management, es casi como un producto ESB ligero, que asume responsabilidades como el balanceo de carga, enrutamiento, monitoreo, el análisis, autenticación, autorización y la liberación controlada. Normalmente no transforma ni interactúa con los sistemas backend más allá de simples llamadas HTTP.

El API Management invoca una implementación de API, normalmente a través de HTTP/REST con un payload JSON. La implementación de una API aún podría hacerse con un producto de bus de servicio tradicional, pero eso es muy poco probable y deseable. Puede implementarse mucho más fácilmente utilizando tecnología genérica como NodeJS o Java (por ejemplo, basada en SpringBoot) y desplegarlo en un contenedor que pueda escalarse fácilmente en una plataforma de contenedores como Kubernetes. O, dada la naturaleza Stateless(sin estado) y la necesidad potencial de manejar altos peaks, sería atractivo adoptar una implementación serverless para la API.

Evidentemente, esta evolución conduce a una mayor escalabilidad y a una reducción de la sobrecarga en la administración de la plataforma de ejecución. En comparación con el estilo de desarrollo frecuentemente declarativo en la plataforma ESB, puede haber una cierta pérdida inicial en la productividad del desarrollo. Esto se compensa fácilmente con el mejor soporte de herramientas para la automatización del CI/CD y también con la mayor disponibilidad de desarrolladores capaces y dispuestos a utilizar tecnologías modernas y genéricas en comparación con los productos de plataformas propietarias específicas de los proveedores.

Integracion horizontal

Muchas Integraciones no son sincrónicas, no involucran a los consumidores con una solicitud urgente y pueden ser desencadenadas por eventos del sistema o simplemente por el tiempo. Estas interacciones suelen tener lugar en segundo plano de forma asíncrona. Estas interacciones tienen que ser observadas mientras se ejecutan en segundo plano. ¿Se completan con éxito? ¿Pueden sobrevivir a la indisponibilidad temporal del sistema de destino? ¿El tiempo de procesamiento seguirá siendo aceptable cuando aumente el volumen?

En la implementación de estas interacciones es fundamental el uso de una cola de mensajes o un bus de eventos, un mecanismo de desacoplamiento que proporciona un puente entre dominios, sistemas, ubicaciones (cloud & on Premises), tecnologías y tiempo. Este bus de eventos también permite el balanceo de carga entre múltiples procesadores, y es un elemento crucial en la gobernanza.

Al identificar estas integraciones horizontales, queda más claro, que patrones como CQRS (Command Query Responsibility Segregation), Event Sourcing, Microservice (interacción y coreografía), así como los pipelines de datos para IoT, Data Warehouses y Data Lakes, se encuentran en el mismo espectro de integración de datos – diferenciándose principalmente con el propósito y estos desencadenan movimiento inmediato de los datos (y tal vez en el volumen y tiempo critico), pero sin diferir en ningún aspecto fundamental.

Las claves en todos los casos de integración son

cuándo: identificar quien activa la acción para ejecutar la integración

qué: extraer los datos necesarios

cómo: publicar los datos de forma que sean accesibles a los potenciales consumidores (ubicación, formato común, tiempo, tecnología, escalabilidad)

supervisar: manejar el “flujo no feliz”

Algunos casos de uso tienen que lidiar con altos volúmenes de datos que necesitan ser procesados en tiempo casi real (Near Real Time).

Los conectores o adaptadores pueden desempeñar un papel en la detección de eventos en aplicaciones estándar y servicios SaaS y en la extracción de los datos relevantes, así como en la entrega de estos eventos a los sistemas de destino. Las ofertas maduras de iPaaS aportan valor proporcionando una plataforma escalable con adaptadores, gestión de ejecuciones de flujos de integración, capacidades para detectar y gestionar excepciones y en despliegues basados en ambientes Cloud-Cloud; y ambientes Cloud y OnPremises.

Una plataforma de integración como servicio, o iPaaS, es un servicio basado en la nube que integra sus datos, aplicaciones y procesos. iPaaS automatiza y simplifica las actividades de integración, facilitando la conexión de aplicaciones y datos desplegados en cualquier entorno. Con iPaaS, puede crear y desplegar integraciones Cloud entre sus aplicaciones y datos además de Cloud – OnPremise, sin tener que instalar o gestionar ningún middleware o hardware.

API Management

Ahora queremos hacer un paréntesis, para comentar de los Productos API Management y en general sobre la gestión de API, que está cobrando cada vez más importancia en las arquitecturas de software, y es extraño encontrar organizaciones que no tengan en su hoja de ruta IT implantar o implementar un sistema bajo este propósito. Podemos definir un entorno API Management, como aquel proceso que permite al negocio exponer servicios de información, bien documentados de una forma segura y escalable, de tal manera que pueda sacar un beneficio. Para ello necesitará una forma de exponer y compartir dichos servicios, así como también poder analizar el comportamiento de estos.

Un API Management esta conformado por los siguientes componentes:

API Gateway: Componente que tiene la función principal de habilitar la interconexión entre los servicios y los consumidores a través de APIs prublicadas en él.

Elementos

1. Routing
2. Soporte Multi-Protocol
3. Monitoring
4. Políticas de seguridad
5. Políticas de uso

API Manager: La principal responsabilidad es la de ofrecer a los p´roveedores capacidades de alta configuración y publicación de sus APIs en el Api Gateway

Elementos

1. Publicación
2. edición
3. Gestor del ciclo de vida
4. Gestor de políticas de uso
5. Consumo
6. Gestor de políticas de seguridad

API Portal: Componente dedicado a recopilar toda la información necesaria para los consumidores, sobre las APIs Publicadas en el API Gateway

Elementos

1. Comunidad de desarrollo
2. Buscador de Api(Navegador interno)
3. Apis Store
4. Testing
5. Documentación

En términos generales, las APIs hacen posible la interconexión de módulos y aplicaciones, facilitando el acceso a sus backends y permitiendo la reutilización de servicios.

Por lo tanto, los puntos básicos de diseño que toda estrategia API Management debe tener en cuenta son:

• Diseño de los servicios: Los servicios deben diseñarse de una forma coherente, representando elementos de negocio. Ya que no se nos debe olvidar, la idea es utilizar estos servicios como un activo más. Es por esto que debemos alejarnos de diseños orientados a tecnología y los conceptos de negocio deben de reflejarse en el diseño de servicios de una forma clara.
• Documentacion: Los APIs deben de estar bien documentados para que se sepa su funcionamiento y cómo interactuar con ellos de una forma independiente.

De esta forma cualquier persona externa a la empresa/compañia podría llegar a construir un producto de manera independiente sobre dicha API.

• Publicación: Uno de los aspectos más importante es de la estrategia API Management es la capacidad de que los servicios de información sean localizados, es por esto recomendable la utilización de algún tipo de portal para la publicación de estos servicios, facilitando así su localización
• Seguridad: Es importante que se establezca un modelo robusto de seguridad sobre las API (Servicios). Para esto es necesario que se compruebe quien tiene acceso a los recursos y bajo que circunstancias. Modelos como OAuth y OpenID pueden ayudarnos en este punto.
• Analítica: Es importante saber y conocer cual es el uso que se hace de un API, saber quien lo consume y de qué forma.

Sirve como indicador a las Áreas de negocio para saber si un API consigue los valores esperados en

• Escalabilidad: El hecho de exponer los servicios de información a terceros y el abrir la posibilidad de crear nuevas aplicaciones hace que exista la posibilidad de un incremento de llamadas a esos servicios, y por lo tanto incremento de llamadas a los servicios backend.

Es por esto, que es importante, que las Arquitecturas de API Management sean robustas en cuanto a escalabilidad, para soportar grandes cargas asociadas a su uso.

Conclusión

Es importante reconocer que, por un lado, hay muchos flujos de datos en los entornos TI que son realmente muy similares; en esencia, se llevan datos de A a B. Se puede ganar mucho al abordar todos estos flujos como parte del mismo tipo. Por otro lado, los distintos matices de los flujos de datos en una visión de integración también requieren diferentes enfoques.

Los modelos de datos comunes, el diseño impulsado por el dominio y el deseo de desacoplamiento, y escalabilidad dinámica son similares, pero las tecnologías de implementación serán diferentes. Ya no deberíamos usar la plataforma ESB, el martillo que puede asumir cualquier desafío de integración de datos como un clavo.

Como primer paso, liberemos interacciones sincrónicas que admiten clientes en línea, como portales web y aplicaciones móviles de ESB. Adoptemos API Management para la implementación de API escalable, quizás primero a través de contenedores y, finalmente, mediante una implementación serverLess. Y adoptemos colas de mensajes o un bus de eventos que sea escalable, accesible entre tecnologías y que este distribuido, confiable y que abarque las nubes y las instalaciones OnPremise.

También queremos destacar que al abordar soluciones IPaas, creemos que se debe tener en cuenta lo siguiente:

En la mayoría de las organizaciones, el cambio a una solución iPaaS suele ser un enfoque paso a paso y muchas empresas conservarán ESB y otras arquitecturas legadas durante un período de tiempo, a medida que modernizan su infraestructura de datos y aplicaciones. Aquí hay algunas ideas que queremos compartir.

Primero, evalúe a los proveedores de iPaaS para los siguientes requisitos técnicos:

• Integraciones impulsadas por metadatos frente a enfoques programáticos
• Experiencia de usuario de Drag&Drop que permite cierto grado de autoservicio
• Conectividad prediseñada (minimización de la codificación)
• Gestión y supervisión basadas en la nube, incluida la gestión integral de errores, soporte transaccional, transformación de datos y otras operaciones.
• Un modelo de implementación híbrido que respeta la importancia de los datos y permite que el procesamiento se ejecute cerca de las aplicaciones, independientemente de dónde residan.

Además, si su organización se está transformando en una empresa basada en la nube donde se valora la agilidad, asegúrese de profundizar en los aspectos de plataforma de iPaaS y asegúrese de no quedar atrapado en una tecnología que solo es adecuada para un estilo de integración. Se debe crear una solución iPaaS para exponer y consumir microservicios y poder manejar la integración de aplicaciones en tiempo real, así como los nuevos requisitos de integración de big data que impulsan el análisis predictivo, el marketing digital y las iniciativas centradas en el cliente.

Si bien la integración no es ciertamente un desafío nuevo de TI, todavía hay muchas ideas antiguas e incluso tecnologías que deben reconsiderarse a medida que crece la adopción de aplicaciones en la nube y surgen nuevos enfoques para manejar los requisitos de big data.

La buena noticia es que, cada vez más, se está produciendo una gran innovación en el mercado de la integración. Como resultado, iPaaS también está ganando aceptación y adopción de TI empresarial.