Actualmente es muy sonado el mundo de las APIS y el API Management, pero vamos a ver cómo hemos llegado hasta ahí, es decir, vamos a tratar un poco la evolución histórica de las diferentes tecnologías de integración. Creo además que siempre nos ayuda a tener una mejor visión del porqué de las cosas, si conocemos de dónde venimos.
Las diferentes Arquitecturas de Integración, digamos que se pueden clasificar en 4 tipos:
Demos un repaso a las principales técnicas de integración, con estándares y protocolos que se usan.
Surgió en los años 70 como un sistema de comunicación que permite intercambiar cualquier tipo de documento electrónico (pedidos, albaranes, facturas, inventarios, catálogos de precios, etc.), todo con un formato normalizado entre los sistemas/empresas de quienes intervienen.
Al final este formato es único y de común acuerdo entre los diferentes intervinientes, donde algunos de los estándares más extendidos son el uso de código de barras, el ASC X12 y el EDIFACT.
Es el primer protocolo de estandarización de comunicaciones electrónicas entre empresas.
Algunas de sus características son:
Permite comunicar aplicaciones que inicialmente no estaban pensadas para comunicarse entre ellas. ESB permite ofrecer una plataforma común con capacidades y el uso de:
Nacieron para evitar el código espagueti de los EDI y las conexiones punto a punto, lo cual generaba una gran “maraña” de conexiones poco reutilizables haciendo muy complejas las arquitecturas de red de una empresa.
Algo que no terminó de funcionar muy bien con los ESB es quien está consumiendo qué servicios, es decir, la autenticación/autorización, ya que resultaba muy compleja.
Lo bueno de los ESBs es que canalizaban todas las comunicaciones de una empresa a través de un mismo canal, gracias a su gran flexibilidad y adaptación antes los diferentes patrones de intercambio de mensajes
Algunas de sus características son:
- Estandarización: se pueden desarrollar marcos, patrones y mejores prácticas para crear servicios reutilizables.
- Bajo acoplamiento:
- Escalabilidad y confiabilidad: El acoplamiento flexible físico brinda ventajas de escalabilidad, como alta disponibilidad, tolerancia a fallos y equilibrio de carga.
- Enrutamiento y mediación.
- Patrones de intercambio de mensajes complejos: Permite intercambios de mensajes más complejos como la mensajería unidireccional asíncrona y a múltiples suscriptores.
Al final es un concepto que aparecen por la necesidad de la asincronía que implica el intercambio de datos entre aplicaciones utilizando un canal de comunicación que transporta unidades de información independientes
Es una parte clave de las arquitecturas ESB, ya que proporciona los fundamentos de las redes y canales virtuales que un ESB usa para enrutar
Es la base para un patrón de asincronía con características de
Algunas de sus características son:
Permite la administración de transferencias de datos segura y de gran volumen entre empresas.
Es la alternativa a los protocolos FTP, SMTP o HTTP, que no permite su administración, gracias a que proporcionan un portal de administración con unas analíticas que fortalecen la tecnología y la dan una mayor seguridad.
Algunas de sus capacidades son:
Algunas de sus características son:
Está intrínsecamente relacionado con las diferentes herramientas que se pueden usar para recoger la información de diferentes fuentes y agruparla en una sola fuente, posiblemente transformando dicha información en un modelo común de datos.
El patrón de integración de datos vía batch, también es conocido como ETL (Extract/Transform/Load), puesto que al final se recoge toda la información posible de diferentes fuentes (extract) que se transforma a un formato unificado y conocido como modelo común de datos (transform) y se guarda en otro sistema de almacenamiento (load).
Así este almacenamiento, puede ser explotado por otro sistema en forma de analíticas o para cualquier otra finalidad.
Algunas de las grandes ventajas a considerar son la gran cantidad de datos que se pueden procesar en un momento programado a través de un solo proceso. Esto promueve la eficiencia ya que evita tener que procesar datos cada vez que se reciben.
Este proceso puede llevarse a cabo en cualquier momento, incluso durante un tiempo en que el sistema informático esté inactivo, lo que permite a los operadores priorizar el tiempo de los lotes fácilmente.
En contraposición las desventajas que pueden asociarse son que la información se procesa a una hora programada y no en tiempo real, por lo que a veces pueden ocurrir retrasos en la actualización de las bases de datos maestras teniendo la información desactualizada en las mismas.
Dependiendo de las circunstancias, esto sería perjudicial en una situación en la que los datos deberían actualizarse de inmediato, por ejemplo, cuando se está reservando asientos en un avión.
El patrón de integración de datos en tiempo real o mejor dicho cerca a tiempo real, puesto que al final hay un pequeño lapso por el procesamiento de los mismos, es un patrón muy parecido al patrón Bath o ETL, donde la ingesta de datos se realiza a través de una cola.
El patrón CQRS – Command and Query Responsibility Segregation, se basa en segregar/separar la BBDD en 2, una donde dejas los datos transformados y otra BBDD para la realización de queries de analíticas y/o su explotación.
Una de las principales ventajas es que los datos se procesan inmediatamente lo cual es beneficioso ya que la información se actualiza lo antes posible y es ideal cuando se trata de reservas.
Este proceso no solo promueve la velocidad, sino que también garantiza que la información esté actualizada y no se retrase.
En contraposición, es un proceso muy costoso, ya que a menudo implica modificar las aplicaciones existentes para agregar la publicación de eventos en la cola siendo a veces ni siquiera posible, ya que el origen de la información puede ser una aplicación específica del proveedor que no incluye la capacidad de modificar su lógica para agregar la publicación de eventos.
Las arquitecturas dirigidas a eventos se basan en la asincronía y colas de mensajes principalmente, donde los componentes que se comunican entre ellos mediante mensajes con información, se pueden clasificar según su naturaleza en:
Los patrones de comunicación son principalmente asíncronos y requieren una alta capacidad de escalar.
Las nuevas tecnologías como la programación reactiva, los microservicios o el procesamiento en streaming pueden implementar especialmente bien este tipo de arquitecturas.
Las características principales de una arquitectura dirigida a eventos son:
Algunos de los principales patrones de una arquitectura dirigida a eventos son:
Al final podemos identificar claramente 2 tipologías bien definidas como son
Se trata de un servicio principal/central que controla la orden donde el “event mediator” recoge de una cola principal los eventos y es el servicio encargado de orquestar el flujo que sea necesario entre los diferentes procesos que han de intervenir, donde cada “event processor” ejecuta una tarea simple.
Al final es una topología para cuando hace falta algún nivel de orquestación entre llamadas.
Se trata de una cola de mensajes como Broker, donde cada “event processor” consume un tipo de mensajes/eventos y publica un tipo diferente de mensajes/eventos, donde en contraposición a la “topología mediador”, no existe un mediador.
Hay una pieza que cuando se recibe el evento, lanza el evento a los distintos canales que deben recibir la señal.
API Managment se conforma principalmente de 3 grandes piezas:
Algunos de los aceleradores que se proveen con API Management, frente a la integración tradicional de ESB son:
Las principales diferencias entre las integraciones más tradicionales o legacy y el API Management son:
Como todo software, las APIs deben disponer de un gobierno para asegurar que todas cumplen con las especificaciones técnicas definidas por el departamento IT.
En las grandes compañías, hay como 3 fases o niveles:
Existen alternativas al API Managment más tradicional de REST + JSON como son:
GraphQL: Es un lenguaje de consulta para APIs, que proporciona una descripción completa y comprensible de los datos en su API y brinda a los clientes el poder pedir exactamente lo que necesitan y nada más. Está pensado para interacción en las consultas con las APIs. Por ejemplo, estandariza los nombres de los query parameters para que las aplicaciones consumidoras no tengan que adaptar los nombres dependiendo de la API a la que consultes (Paypal github – expone APIs GraphQL)
gRPC: Remote Procedure Call es un procedimiento donde una aplicación cliente puede llamar directamente a métodos de una aplicación servidor en una máquina diferente como si fuera un objeto local, facilitando así la creación de aplicaciones y servicios distribuidos. Está basado en el protocolo HTTP 2.0, permite comunicaciones más efectivas mediante dos interlocutores conocidos y normalmente se utiliza de forma interna para mejorar el performance, tratando el dato a nivel binario y reduciendo al máximo los bits enviados en la comunicación.
Webhooks: También llamados Reverse APIs, donde el servidor notifica a través de una url de callback registrada, el cambio de un estado al cliente
WebSockets: Proporciona un canal de comunicación bidireccional sobre un único socket TCP
CloudEvents: Es una especificación que describe de forma común y genérica los eventos de datos
AsyncAPI: Es una especificación que describe de forma común y genérica los mensajes de APIs asíncronas. Es un nuevo paradigma vinculado a las arquitecturas EDA (Event Driven Architectures).
Service Mesh complementa las características de Kubernetes, proporcionando un proxy que simplifica las comunicaciones entre microservicios (tráfico este-oeste).
Apareció cuando la tecnología API Gateway tradicional era demasiado pesada para las comunicaciones de microservicio a microservicio, proporcionando un equilibrio de carga automático, reglas de enrutamiento enriquecidas, reintentos, conmutación por error, una capa de política conectable, métricas automáticas, comunicaciones seguras de servicio a servicio, etc.
Algunos ejemplos de soluciones de malla de servicios: Istio y Linkerd.
Algunos vendors de API Management proporcionan adaptadores para Istio, que se pueden usar para administrar los servicios expuestos fuera de la malla de servicios de Istio o entre servicios que se ejecutan completamente dentro de la malla.
El Internet de las cosas (IoT) es un sistema de dispositivos interrelacionados que cuentan con identificadores únicos y la capacidad de transferir datos a través de una red sin necesidad de interacción humana
Algunos de los desafíos a los que se deben enfrentar son:
Una plataforma de dispositivos IoT, se caracteriza a alto nivel por 4 capas:
Algunos de los estándares técnicos usados por las diferentes plataformas de integración son:
Según Gartner, la plataforma de integración como servicio (iPaaS) es “un conjunto de servicios en la nube que permite el desarrollo, la ejecución y la gobernanza de los flujos de integración que conectan cualquier combinación de procesos, servicios, aplicaciones y datos locales y basados en la nube dentro de un individuo o entre múltiples organizaciones”.
Una plataforma de integración híbrida combina capacidades de integración local y en la nube, tales como: integración de datos (ETL, en tiempo real), integración de aplicaciones, B2B EDI, MFT, mensajería, IoT o administración de API. Como regla general, los artefactos de integración deben implementarse lo más cerca posible a los datos.
Un Data Hub iPaaS está “basado en una arquitectura de centro de datos. La plataforma admite la integración entre las aplicaciones y los puntos finales del sistema a través de un almacén intermediario centralizado que conserva los datos (a menudo normalizados) antes de la entrega al destino”.
Un Data Hub admite datos de todo tipo (relacionales y NoSQL), se centra en la armonización de datos y proporciona funciones de indexación y búsqueda. Los datos se mueven físicamente y se reindexan en un nuevo sistema.
En un Data Lake todos los datos se mueven de silos dispares a un solo sistema, pero rara vez se armonizan o indexan.
El futuro de las arquitecturas de integración es prometedor debido a la creciente necesidad de integrar diferentes sistemas y aplicaciones. A medida que las empresas buscan mejorar su eficiencia y agilidad, las arquitecturas de integración se convierten en una herramienta clave para lograr estos objetivos.
Por ende y bajo mi punto de vista, en el futuro de las arquitecturas de integración se incluye:
En resumen, el futuro de las arquitecturas de integración es prometedor y seguirá evolucionando para satisfacer las necesidades cambiantes de las empresas y los avances tecnológicos.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
