¿Qué es una pasarela federada?

En los sistemas centralizados, una pasarela (conectada y responsable de gestionar varias API) gestiona todas las consultas de los clientes. Mientras tanto, la federación de pasarelas permite a una organización utilizar una red distribuida de pasarelas API, cada una responsable de su propio conjunto distinto de servicios.

En un sistema de pasarela federada, los equipos pueden añadir servicios según sea necesario sin afectar a todo el sistema, lo que permite un uso eficiente de los recursos y una gestión del tráfico. Los departamentos separados también pueden usar diferentes protocolos para administrar sus respectivas pasarelas. El marco da a los equipos la libertad de gestionar sus propias API, mejorando la flexibilidad, la resiliencia operativa y mucho más.

Este enfoque también ayuda a evitar cuellos de botella en el tráfico y otros problemas asociados con las pasarelas API centralizadas y puede ofrecer beneficios de rendimiento al implementar funciones de puerta de enlace más cerca de los usuarios finales. Las estrategias de federación de pasarelas se pueden aplicar a varios estilos y protocolos arquitectónicos de API, incluidos REST, gRPC y SOAP, cada uno de los cuales ofrece beneficios e inconvenientes.

Desde una perspectiva de TI, una pasarela federada es beneficiosa porque permite a los equipos de DevOps desarrollar e implementar sus propias API mientras mantienen la adherencia a las políticas de gestión, gobierno y seguridad de la plataforma de API en toda la empresa. Los equipos pueden actuar con rapidez y autonomía para completar proyectos en su ámbito (facilitando la innovación y acelerando la comercialización) al tiempo que se mantienen los estándares de toda la organización, logrando un equilibrio entre la autonomía de los equipos y la supervisión centralizada.

La federación GraphQL es un concepto alternativo y un método arquitectónico que se utiliza para crear una API GraphQL unificada. Se basa en GraphQL, un lenguaje de consulta que puede dirigirse con precisión a recursos de varios servicios con una única consulta API.

La federación GraphQL conecta diferentes servicios (conocidos como subgráficos), cada uno con su propio esquema que define los datos que administra, a un esquema unificado conocido como supergráfico. Una única pasarela expone este esquema de supergráfico a las aplicaciones cliente, une múltiples servicios y campos subyacentes y enruta todas las consultas de API. Por el contrario, la federación de pasarelas conecta múltiples pasarelas API a través de un plano de control central, y cada puerta de enlace responde a sus propias consultas.

La federación es un enfoque general de la gestión de sistemas que conecta componentes autónomos a través de un plano de control común.

En un sistema de pasarela centralizada, todas las solicitudes de los clientes fluyen a través de una única pasarela, que gestiona funciones como el enrutamiento, la autenticación, la autorización y la monitorización. A diferencia de las arquitecturas federadas, estas responsabilidades no se distribuyen entre varias instancias.

Este enfoque puede agilizar la información de registro, la gestión del tráfico, la aplicación de la seguridad y otras tareas, ya que cada uno de estos procesos fluye a través de la pasarela. Las organizaciones también pueden iniciar las implementaciones desde un único punto, eliminando la necesidad de actualizar las versiones en múltiples pasarelas y servicios.

Sin embargo, las empresas con marcos centralizados pueden tener más probabilidades de encontrar cuellos de botella, especialmente a medida que amplían sus operaciones. Como único punto de paso del sistema, la pasarela puede congestionarse fácilmente. Además, presenta un único punto de fallo; si se produce un error, afecta a todo el sistema.

A diferencia de los sistemas centralizados, las arquitecturas de pasarela federada se componen de múltiples puertas de enlace, cada una responsable de un conjunto distinto de servicios y API asociadas. Las pasarelas funcionan de forma independiente, aunque cada una de ellas está gestionada por un plano de control central.

En comparación con los marcos centralizados, los sistemas federados promueven la flexibilidad y la autonomía al brindar a los equipos de desarrollo un mayor nivel de control sobre sus respectivos dominios. Este diseño descentralizado también hace que los sistemas federados sean más resilientes frente a interrupciones y fallos del sistema.

Sin embargo, los sistemas federados son más complejos desde el punto de vista operativo, lo que puede introducir disparidades de gobierno y falta de comunicación entre los equipos. Las implementaciones pueden tardar más y el mantenimiento puede ser más costoso, ya que cada pasarela debe administrarse y actualizarse por separado.

Hay varias razones por las que una empresa puede optar por un sistema de pasarela federada.

Por un lado, la federación de pasarelas se utiliza habitualmente en casos de fusiones y adquisiciones, en los que una empresa hereda diferentes pilas tecnológicas y sistemas de gestión de API de las empresas que adquiere. En lugar de gestionar individualmente varias arquitecturas separadas, cada una con protocolos de seguridad, estándares técnicos y estructuras de gobierno distintos, o intentar adaptar los sistemas adquiridos con los sistemas empresariales existentes, las empresas recurren a la federación de pasarelas. Este enfoque permite a las organizaciones integrar las pasarelas API existentes y sus sistemas subyacentes en la estructura superpuesta proporcionada por el plano de control central.

Del mismo modo, las pasarelas múltiples se utilizan a menudo en entornos con muchos microservicios creados por diferentes equipos y distribuidos en diferentes entornos. Una empresa también puede elegir un sistema federado para obtener beneficios de rendimiento.

Por ejemplo, imagine una empresa de logística con varias oficinas en todo el mundo, cada una de las cuales presta servicio a una región concreta. Al colocar pasarelas, servidores, servicios y otros recursos más cerca de los clientes que acceden a ellos, la empresa puede optimizar la latencia y los factores de rendimiento relacionados.

En la federación de pasarelas, el plano de control central se encarga de la gestión, la monitorización y el gobierno, pero por lo general es inaccesible para los clientes. Los consumidores de API interactúan directamente con las pasarelas que forman el sistema federado (consultan el endpoint responsable de los servicios pertinentes), pero no consultan el propio plano de control. El avión recibe los metadatos y los registros solo cuando ya se ha realizado una llamada a la API.

Aunque este enfoque puede introducir cierta complejidad operativa, también promueve la independencia. Por ejemplo, ayuda a los equipos de plataformas a configurar sus propias pasarelas y servicios para satisfacer sus necesidades específicas, elegir sus propios protocolos e implementar implementaciones por su cuenta. Las arquitecturas federadas también son más resistentes a los errores de configuración y a las violaciones de seguridad, ya que los errores se aíslan en la pasarela en la que se originaron y no es probable que se propaguen a otras pasarelas de la red.

En la federación GraphQL, mientras tanto, los esquemas de múltiples servicios independientes (subgrafos) se combinan en un esquema de supergrafo unificado. Una única pasarela, o enrutador, presenta un único punto de entrada para las consultas de los clientes, proporcionando una experiencia API unificada.  

El enrutador divide de manera inteligente las consultas en subsolicitudes más pequeñas, recuperando información relevante de múltiples subgrafos y compilándola en una respuesta cohesiva para los clientes.

Imagine una plataforma sanitaria con servicios separados para:

• Pacientes: gestión de los datos del paciente, la información de contacto y los historiales médicos
  
  
• Citas: programación y seguimiento de las próximas visitas
  
  
• Facturación: gestión de facturas y notificaciones de facturación

En lugar de consultar cada uno de estos endpoints con una llamada API independiente, la federación GraphQL presenta una interfaz unificada que permite a los clientes (en este caso, un panel de control o una aplicación que atiende a médicos o pacientes) acceder al historial médico de un paciente, identificar su próxima cita y determinar su saldo pendiente con una sola llamada a la API, en lugar de tres solicitudes separadas.

La federación GraphQL proporciona una forma de crear una API GraphQL escalable en un entorno distribuido. El marco permite el desarrollo y la implementación independientes de servicios al tiempo que proporciona una interfaz unificada para las consultas de los clientes. Sin embargo, la federación GraphQL puede ser propensa a desafíos de coste y complejidad, vulnerabilidades de seguridad, congestión y redundancias.

Introducida en 2019, la federación Apollo es una implementación de la federación GraphQL que utiliza directivas especiales (como @key o @extends) dentro del lenguaje de definición de esquema GraphQL para definir relaciones entre diferentes tipos en los subgráficos.

Aunque Apollo es una solución común, no es la única opción de federación de GraphQL disponible. Las alternativas comunes incluyen Hive, Mesh, Indigo y WunderGraph Cosmo, cada una de las cuales ofrece diferentes niveles de personalización. 

Aunque menos del 5 % de las empresas habían federado sistemas GraphQL en 2024, se espera que esa cifra alcance el 30 % en 2027, según la empresa de investigación Gartner. Los principales proveedores de servicios en la nube como Amazon Web Services (AWS) y Microsoft Azure, así como repositorios de código como GitHub, también son compatibles con las API GraphQL con herramientas integradas de observabilidad y validación.

La federación GraphQL tiene varias ventajas distintas, especialmente en su capacidad para optimizar el acceso a la API para los clientes. Los equipos pueden mantener un grado de independencia implementando, gestionando y escalando sus propios subgrafos.

Pero como marco centralizado, la federación GraphQL es más vulnerable a fallos de seguridad, problemas de congestión e ineficiencias de rendimiento. También está en deuda con los esquemas GraphQL, mientras que la federación de la pasarela API es compatible con varios protocolos.

Al desarrollar una estrategia de API, las organizaciones deciden si adoptar un marco de API GraphQL o utilizar otro estilo arquitectónico, como REST, para sus API.

En última instancia, las organizaciones pueden optar por incorporar la federación de GraphQL y otros estilos arquitectónicos en sus sistemas, y cada uno es responsable de gestionar diferentes funciones. En una configuración común, una empresa utiliza GraphQL internamente (con barreras estrictas para mitigar los problemas de seguridad, coste o complejidad) y utiliza un estilo arquitectónico diferente, como REST (que puede proporcionar un nivel de control más profundo y una adopción más fácil) para las API externas. En este escenario, también se podría utilizar una pasarela API para unificar estos estilos arquitectónicos dispar a través del plano de control central.

En las configuraciones estándar de pasarelas API, una única pasarela gestiona todo el tráfico, el enrutamiento y los análisis de los usuarios. Aunque este enfoque ayuda a agilizar las configuraciones más sencillas, puede provocar rápidamente cuellos de botella en entornos más complejos.

Las pasarelas federadas no dependen de una única puerta de enlace API, sino de una serie de ellas. Cada pasarela se utiliza para gestionar las llamadas API a un conjunto específico de servicios, y las pasarelas están conectadas al plano de control, que se encarga de la gestión y el gobierno.

Las mallas de servicios, por su parte, se consideran configuraciones de este a oeste porque gestionan las conexiones entre microservicios pero no interactúan con los propios usuarios. Las mallas de servicios facilitan principalmente la comunicación y la observabilidad en un único entorno o clúster. Sin embargo, las variantes conocidas como mallas de cloud híbrido están optimizadas para realizar funciones como el cifrado, el equilibrio de carga y la autenticación en múltiples clústeres y entornos (incluidos entornos de multinube, de cloud híbrido y on-premises). 

Las organizaciones pueden utilizar diversas estrategias para aprovechar la arquitectura distribuida de una pasarela federada y, al mismo tiempo, reducir algunas de las complejidades operativas y los costos de mantenimiento asociados a los sistemas federados. Estas prácticas ayudan a preservar la autonomía del equipo al tiempo que mantienen abiertas las líneas de comunicación y la supervisión unificada entre los equipos.

Las empresas deben establecer distinciones claras entre los equipos, eliminando las ambigüedades en torno a los servicios que cada uno se encarga de crear y mantener. Esta práctica promueve la responsabilidad y protege a los equipos de la duplicación o configuración incorrecta inadvertida del trabajo de los compañeros. Por extensión, este enfoque puede aumentar la productividad porque los equipos tienen una comprensión firme de sus objetivos y responsabilidades (y la libertad de actuar en consecuencia).

La implementación inconsistente de protocolos y estándares de seguridad y cumplimiento en todas las pasarelas y API puede presentar riesgos de seguridad, legales y de reputación. Mantener los estándares de información de registro, cifrado, autenticación y otras implementaciones de seguridad en las pasarelas debe ser una prioridad en un sistema distribuido. Esto ayuda a garantizar que el plano de gestión central se pueda utilizar para responder eficazmente a los informes de incidentes, realizar auditorías exhaustivas y prevenir futuros ataques, independientemente del dominio desde el que se haya originado una amenaza.

Las brechas de observabilidad en un sistema distribuido pueden generar riesgos de seguridad y problemas de rendimiento. Es crucial que el plano de gestión central proporcione la visibilidad completa necesaria para que los equipos vean el estado y el rendimiento del sistema. Esta capacidad ayuda a permitir una corrección rápida cuando surgen problemas, así como a la posibilidad de realizar mejoras proactivas basadas en métricas de seguridad y rendimiento.

Los portales unificados para desarrolladores actúan como centros centralizados donde los desarrolladores pueden acceder y obtener información sobre cualquier API del sistema, independientemente de dónde estén alojadas o cómo estén estructuradas. Son especialmente importantes en los sistemas federados porque proporcionan directrices, documentación y ejemplos de codificación para dar a los equipos de DevOps un marco claro sobre cómo deben construirse, implementarse y mantenerse sus API.

Estos estándares universales, junto con las claves de API y otros controles de acceso, ayudan a garantizar que los desarrolladores puedan agregar API al sistema de manera fluida y administrar sus propias pasarelas, manteniendo la seguridad y la coherencia.

Dado que cada equipo actúa con cierto grado de autonomía, es fundamental mantener líneas de comunicación abiertas para compartir buenas prácticas y mantener una red sostenible. Los paneles de control y otras herramientas de colaboración pueden ayudar a los equipos a sincronizarse en torno a objetivos y procedimientos compartidos, especialmente cuando un cambio en un dominio puede afectar a los servicios relacionados.

Los mecanismos de generación de informes exhaustivos permiten a los equipos de DevOps detectar y resolver rápidamente la latencia, las interrupciones del servicio y otras anomalías, lo que contribuye a una experiencia de usuario más fluida. Las métricas de rendimiento también pueden mejorar la eficiencia de la escala al identificar qué partes del sistema están alcanzando su capacidad y cuáles tienen un rendimiento inferior.

Los enfoques modernos de DevOps, como la infraestructura como código (utilizando código para automatizar procesos de TI que de otro modo requerirían supervisión y aprovisionamiento manuales) y AIOps (utilizando IA para agilizar las operaciones de TI) pueden ayudar a las pasarelas federadas a funcionar de forma más eficiente. Las técnicas de automatización también contribuyen a una red más resiliente porque reducen la probabilidad de errores humanos y dan a los equipos de TI ancho de banda para centrarse en problemas más complejos.

La federación de pasarelas combina la flexibilidad y la personalización de las arquitecturas descentralizadas con una estructura de gobierno centralizada y puede ofrecer varias ventajas sobre las arquitecturas tradicionales.

La federación brinda a los equipos control sobre sus propias pasarelas, lo que les permite ajustar las configuraciones de tiempo de ejecución, administrar actualizaciones y personalizar los entornos de codificación para satisfacer mejor las necesidades de sus clientes y servicios. Por ejemplo, para ajustar el límite de velocidad de una API en un sistema centralizado, un equipo tendría que enviar una solicitud a través de la pasarela única de la organización. Los sistemas federados permiten a los equipos realizar el ajuste de forma independiente y en tiempo real, sin afectar a otras pasarelas de la red.

El plano central ayuda a garantizar que varias pasarelas, a pesar de tener sus propias configuraciones, cumplan con estándares de seguridad y compatibilidad compartidos. Los equipos tienen la flexibilidad de ajustar los parámetros de forma autónoma mientras se benefician de la supervisión externa proporcionada por el plano de control.

Los enfoques federados reconocen que los equipos de desarrollo a menudo tienen la mejor idea de cómo mejorar y mantener sus propios dominios. Los equipos tienen autonomía para ajustar sus API o servicios en cuanto ven que surge un problema, lo que mejora la adaptabilidad y la agilidad. 

Los equipos pueden incluso trabajar en diferentes lenguajes de codificación mientras mantienen la relación de su servicio con el plano de control central. Por último, los departamentos pueden lanzar las actualizaciones según sea necesario en lugar de depender de una autoridad central para aprobar los cambios, lo que mejora el tiempo de comercialización de las nuevas características y agiliza los flujos de trabajo.

Los sistemas federados pueden ofrecer un aprovisionamiento de recursos más eficiente al permitir a los equipos monitorizar su propio rendimiento y ajustar los límites de velocidad y las distribuciones de tráfico en consecuencia. Las organizaciones pueden ampliar solo los servicios y funciones que requieren capacidad adicional, canalizando recursos de servicios o regiones menos utilizados a aquellos que experimentan una mayor demanda.

Además, como las pasarelas API son independientes, es más difícil que las vulnerabilidades salten de una pasarela a otra. Como resultado, los sistemas federados suelen ser más resilientes a los ataques y las interrupciones porque es probable que los fallos afecten a una sola pasarela, en lugar de a todo el sistema.

En los sistemas federados, los equipos individuales de DevOps asumen la operación y el mantenimiento de sus propias pasarelas. Con menos responsabilidades, el equipo central puede centrarse en cuestiones de mayor nivel, como hacer cumplir las normativas de cumplimiento, facilitar la comunicación cruzada entre equipos y perfeccionar las arquitecturas del sistema.

Los silos de datos son mucho menos probables porque una pasarela federada puede analizar el rendimiento y aplicar medidas de seguridad en todos los dominios. Las métricas entre pasarelas pueden proporcionar una visión más integral de cómo un servicio en particular impacta en los productos y servicios relacionados.

La propiedad descentralizada y la flexibilidad pueden presentar varios desafíos, especialmente cuando hay fallos en el gobierno o la observabilidad. Los desafíos introducidos por las pasarelas federadas incluyen:

Aunque la autonomía del equipo puede ayudar a impulsar la innovación, también añade complejidad arquitectónica al sistema, lo que aumenta los costes de infraestructura y computación. Los sistemas federados también tienden a requerir más recursos de mantenimiento y seguridad debido a su estructura descentralizada.

Como las métricas y los registros se distribuyen a través de múltiples pasarelas API, puede ser más difícil para las organizaciones construir una imagen cohesiva del rendimiento general del sistema. Las fuentes de datos pueden fragmentarse y desconectarse de la red en general, lo que dificulta identificar y solucionar posibles errores de configuración. Las organizaciones pueden abordar este desafío con protocolos y principios de estandarización sólidos y con herramientas de observabilidad.

Si bien los equipos individuales pueden realizar actualizaciones según su propio criterio, las implementaciones en toda la empresa pueden tardar más que en los entornos centralizados. En lugar de actualizar una única base de código central, las pasarelas federadas deben distribuir las actualizaciones en varios dominios, y cada equipo es responsable de aprobar e integrar esos cambios de forma independiente.

Mantener configuraciones y políticas coherentes en todas las pasarelas distribuidas puede suponer un reto. Si los equipos adoptan protocolos, calendarios de implementación y formatos de datos que se desvían de los estándares de gobierno empresarial, pueden surgir incompatibilidades y vulnerabilidades de seguridad. Por el contrario, si las normas y las políticas de gobierno se vuelven demasiado estrictas, las empresas corren el riesgo de sofocar la experimentación y ralentizar el ritmo de la innovación. En un sistema federado, el equilibrio es crucial.

A medida que las empresas crecen y evolucionan bajo un sistema federado, corren el riesgo de introducir nuevas ineficiencias, como la proliferación de API, cuando varios equipos desarrollan involuntariamente API redundantes. Si este problema se agrava, las pasarelas pueden volverse inmanejables y el plano central no podrá rastrear los cambios. Este problema se puede mitigar mediante un gobierno eficiente.