¿Qué es una puerta de enlace federada?

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

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

Este enfoque también ayuda a evitar cuellos de botella en el tráfico y otros problemas asociados con las API Gateway centralizadas y puede ofrecer beneficios de rendimiento al desplegar funciones de puertas de enlace de API más cerca de los usuarios finales. Las estrategias de federación de puertas de enlace 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 puerta de enlace federada es beneficiosa porque permite a los equipos de DevOps desarrollar y desplegar sus propias API mientras mantienen la adherencia a las políticas de gestión, gobernanza 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 de GraphQL es un concepto alternativo y un enfoque arquitectónico que se emplea para crear una API de GraphQL unificada. Se basa en GraphQL, un lenguaje de consulta que puede orientar con precisión recursos de múltiples servicios con una sola consulta API.

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

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

En un sistema de puerta de enlace centralizada, todas las solicitudes de los clientes pasan por una única puerta de enlace, que gestiona funciones como el enrutamiento, la autenticación, la autorización y el monitoreo. A diferencia de las arquitecturas federadas, estas responsabilidades no se distribuyen entre varias instancias.

Este enfoque puede agilizar el registro, la gestión del tráfico, la aplicación de la seguridad y otras tareas porque cada uno de estos procesos fluye a través de la puerta de enlace. Las organizaciones también pueden iniciar implementaciones desde un solo punto, eliminando la necesidad de actualizaciones de versiones en múltiples puertas de enlace y servicios.

Sin embargo, es más probable que las empresas con marcos centralizados encuentren cuellos de botella, especialmente a medida que escalan sus operaciones. Como único punto de paso del sistema, la puerta de enlace 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 puerta de enlace federadas se componen de varias puertas de enlace, cada una responsable de un conjunto distinto de servicios y API asociadas. Las puertas de enlace funcionan de forma independiente, aunque cada una de ellas está gestionada por un plano de control central.

En comparación con los marcos centralizadas, 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 contra interrupciones y fallas del sistema.

Sin embargo, los sistemas federados son operativamente más complejos, lo que potencialmente introduce disparidades de gobernanza y falta de comunicación entre equipos. Las implementaciones pueden llevar más tiempo y el mantenimiento puede ser más costoso, porque cada puerta de enlace debe gestionar y actualizar por separado.

Existen varias razones por las que una empresa podría optar por un sistema de puerta de enlace federada.

Por un lado, la federación de puertas de enlace 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 gobernanza distintas, o intentar adaptar los sistemas adquiridos con los sistemas empresariales existentes, las empresas recurren a la federación de puertas de enlace. Este enfoque permite a las organizaciones integrar las puertas de enlace de API existentes y sus sistemas subyacentes en la estructura superpuesta proporcionada por el plano de control central.

Del mismo modo, las puertas de enlace 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, considere una empresa de logística con varias oficinas en todo el mundo, cada una de las cuales presta servicios a una región en particular. Al colocar puertas de enlace, 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 puertas de enlace, el plano de control central maneja la gestión, el monitoreo y la gobernanza, pero generalmente es inaccesible para los clientes. Los consumidores de API interactúan directamente con las puertas de enlace que componen el sistema federado (consultando el endpoint responsable de los servicios relevantes), pero no consultan el plano de control en sí. El plano recibe metadatos y registros solo después de que ya se haya producido una llamada a la API.

Si bien este enfoque puede introducir cierta complejidad operacional, también promueve la independencia. Por ejemplo, ayuda a que los equipos de plataforma configuren sus propias puertas de enlace y servicios para satisfacer sus necesidades específicas, elegir sus propios protocolos y desplegar implementaciones por su cuenta. Las arquitecturas federadas también son más resistentes a las configuraciones erróneas y a las violaciones de seguridad, ya que los errores se aíslan en la puerta de enlace desde la que se originaron y no es probable que se propaguen a otras puertas de enlace de la red.

En la federación GraphQL, mientras tanto, los esquemas de múltiples servicios independientes (subgráficos) se combinan en un esquema de supergráficos 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 forma inteligente las consultas en subsolicitudes más pequeñas, recuperando información relevante de múltiples subgráficos y compilándola en una respuesta cohesiva para los clientes.

Imagine una plataforma de atención médica con servicios separados para:

• Pacientes: gestión de detalles de pacientes, información de contacto e historiales médicos
  
  
• Citas: programación y seguimiento de las próximas visitas
  
  
• Facturación: manejo de facturas y notificaciones de facturación

En lugar de consultar cada uno de estos endpoints con una llamada API separada, la federación de GraphQL presenta una interfaz unificada que permite a los clientes (en este caso, una aplicación o panel 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 de GraphQL proporciona una forma de crear una API GraphQL escalable en un entorno distribuido. La infraestructura permite el desarrollo y despliegue independientes de servicios, al tiempo que proporciona una interfaz unificada para las consultas de los clientes. Sin embargo, la federación de GraphQL puede ser propensa a desafíos de costo 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, que ofrecen diferentes niveles de personalización. 

Si bien menos del 5 % de las empresas tenían sistemas GraphQL federados en 2024, se espera que esa cifra alcance el 30 % para 2027, según la firma de investigación Gartner. Los principales proveedores de la nube como Amazon Web Services (AWS) y Microsoft Azure, así como repositorios de código como GitHub, también admiten las API de 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 desplegando, gestionando y escalando sus propios subgráficos.

Pero como marco centralizado, la federación de 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 puerta de enlace de API es compatible con varios protocolos.

Al desarrollar una estrategia, las organizaciones deciden si adoptar una infraestructura de API GraphQL o emplear 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, costo 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 puerta de enlace de API para unificar estos estilos arquitectónicos dispar a través del plano de control central.

En las configuraciones estándar de puertas de enlace de API, una única puerta de enlace gestiona todo el tráfico, el enrutamiento y los analytics 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 puertas de enlace federadas dependen no solo de una única puerta de enlace de API, sino de una variedad de ellas. Cada puerta de enlace se utiliza para gestionar las llamadas API a un conjunto específico de servicios, y las puertas de enlace están conectadas al plano de control, que se encarga de la gestión y la gobernanza.

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 dentro de un mismo entorno o clúster. Sin embargo, las variantes conocidas como mallas de nube híbrida 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 multinube, de nube híbrida y on premises). 

Las organizaciones pueden usar varias estrategias para beneficiarse de la arquitectura distribuida de una puerta de enlace federada mientras reducen algunas de las complejidades operativas y los costos de mantenimiento asociados con los sistemas federados. Estas prácticas ayudan a preservar la autonomía del equipo mientras mantienen líneas abiertas de comunicación y supervisión unificada entre equipos.

Las empresas deben establecer distinciones claras entre los equipos, eliminando las ambigüedades en torno a qué servicios se encarga de construir y mantener cada uno. Esta práctica promueve la responsabilidad y protege a los equipos de duplicar o configurar incorrectamente el trabajo de los colegas. 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 puertas de enlace y API puede presentar riesgos de seguridad, legales y de reputación. Mantener los estándares de registro, cifrado, autenticación y otras implementaciones de seguridad en todas las puertas de enlace debe ser una prioridad en un sistema distribuido. Esto ayuda a garantizar que el plano de gestión central se pueda utilizar para responder de manera eficiente a los informes de incidentes, realizar auditorías exhaustivas y prevenir futuros ataques, sin importar de qué dominio se originó 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 integral 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 la capacidad de realizar mejoras proactivas basadas en métricas de seguridad y rendimiento.

Los portales de desarrolladores actúan como centros centralizados donde los desarrolladores pueden acceder y aprender sobre cualquier API en el sistema, independientemente de dónde estén alojadas o cómo estén estructuradas. Son especialmente importantes en los sistemas federados porque proporcionan pautas, documentación y muestras de programación para brindar a los equipos de DevOps un marco claro sobre cómo deben construirse, desplegar y mantenerse sus API.

Estos estándares universales, junto con las claves API y otros controles de acceso, ayudan a garantizar que los desarrolladores puedan agregar API al sistema perfectamente y administrar sus propias puertas de enlace mientras mantienen la seguridad y la coherencia.

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

Los mecanismos de informes integrales permiten a los equipos de DevOps detectar y abordar 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 (usando código para automatizar procesos de TI que de otro modo requerirían supervisión y aprovisionamiento manuales ) y AIOps (usando IA para optimizar las operaciones de TI) pueden ayudar a que las puertas de enlace federadas funcionen de manera más eficiente. La 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 puertas de enlace combina la flexibilidad y personalización de arquitecturas descentralizadas con una estructura de gobierno centralizada y puede ofrecer varias ventajas sobre las arquitecturas tradicionales.

La federación da a los equipos el control sobre sus propias puertas de enlace, lo que les permite ajustar las configuraciones de tiempo de ejecución, gestionar actualizaciones y personalizar los entornos de programación para que se adapten mejor a 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 necesitaría enviar una solicitud a través de la puerta de enlace ú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 puertas de enlace de la red.

El plano central ayuda a garantizar que múltiples puertas de enlace, a pesar de tener sus propias configuraciones, cumplan con los estándares de compatibilidad y seguridad compartidos. Los equipos tienen la flexibilidad de ajustar los parámetros de forma autónoma mientras obtienen un beneficio 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 programación mientras mantienen la relación de su servicio con el plano de control central. Por último, los departamentos pueden implementar 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 nuevas características y agiliza los flujos de trabajo.

Los sistemas federados pueden ofrecer un aprovisionamiento de recursos más eficiente al permitir que los equipos supervisen su propio rendimiento y ajusten 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 tienen una mayor demanda.

Además, debido a que las puerta de enlace de API son independientes, es más difícil que las vulnerabilidades salten de una puerta de enlace de API a otra. Como resultado, los sistemas federados son generalmente más resilientes contra ataques e interrupciones porque es probable que las fallas afecten solo a una única puerta de enlace, 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 puertas de enlace. Con menos responsabilidades, el equipo central puede enfocarse en problemas de mayor nivel, como hacer cumplir las regulaciones, facilitar la comunicación cruzada entre equipos y refinar las arquitecturas de sistemas.

Los silos de datos son mucho menos probables porque una puerta de enlace federada puede analizar el rendimiento y aplicar medidas de seguridad en todos los dominios. Las métricas entre puertas de enlace pueden proporcionar una visión más holística de cómo un servicio en particular está afectando a los productos y servicios relacionados.

La propiedad descentralizada y la flexibilidad pueden presentar varios desafíos, especialmente cuando hay fallas en la gobernanza o la observabilidad. Los desafíos introducidos por las puertas de enlace federadas incluyen:

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

Debido a que las métricas y los registros se distribuyen a través de múltiples puertas de enlace de API, puede ser más difícil para las organizaciones crear una imagen cohesiva del rendimiento general del sistema. Las fuentes de datos pueden fragmentarse y desconectarse de la red más amplia, lo que hace que sea más difícil identificar y solucionar posibles errores de configuración. Las organizaciones pueden dirigir 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 a su propia discreción, las implementaciones en toda la empresa pueden llevar más tiempo que en entornos centralizados. En lugar de actualizar un único código base central, las puertas de enlace 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 puerta de enlaces distribuidas puede suponer un reto. Si los equipos adoptan protocolos, calendarios de implementación y formatos de datos que se apartan de las normas de gobernanza empresarial, pueden surgir incompatibilidades y vulnerabilidades de seguridad. Por el contrario, si las normas y las políticas de gobernanza se vuelven demasiado estrictas, las empresas corren el riesgo de ahogar 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 expansión de API, cuando varios equipos desarrollan sin querer API redundantes. Si este problema se intensifica, las puertas de enlace pueden volverse inmanejables, y el plano central no puede rastrear los cambios. Este problema se puede mitigar mediante una gobernanza eficiente.