Actores de gateway distribuido: la evolución de la gestión de API

Por Rajesh Narayanan

Revisado y con contribuciones de: Ian Smith, Sam Bisbee, Andrew Stiefel, Lori MacVittie, Mike Wiley y otros.

Opinión de la Oficina del CTO de F5

El equipo de la Oficina del CTO de F5 lleva más de un año explorando el ámbito tecnológico relacionado con las API. Este último informe técnico da continuidad a nuestros esfuerzos por comprender el ecosistema de las API, en constante evolución.

Los retos que hemos detallado en relación con la gestión de la proliferación de API darán lugar a problemas derivados de la proliferación de puertas de enlace de API, y los enfoques tradicionales para abordar estos retos no serán suficientes. Aunque las tecnologías de grafos como GraphQL resultan muy prometedoras para controlar la complejidad asociada a las API, solo son una parte de la solución, ya que los retos van más allá de la conectividad, la seguridad y el enrutamiento. El enfoque adecuado, basado en casi treinta años de experiencia en el escalado de sistemas y aplicaciones, se fundamenta en una arquitectura distribuida —no federada— que utiliza GraphQL, pero no depende exclusivamente de esta tecnología.

Este documento analiza un enfoque de arquitectura distribuida para abordar los retos derivados de la proliferación de puertas de enlace de API.

Resumen

La economía digital se sustentará en las API, lo que dará lugar a una economía impulsada por API. A raíz del libro blanco sobre la proliferación de API, nos propusimos comprender cómo eliminar o mitigar el impacto de la proliferación de API. Aunque GraphQL parecía prometedor para reducir las consecuencias de dicha proliferación, suele obligar a los desarrolladores a reescribir gran parte del código base de sus API. Sin embargo, está surgiendo una nueva perspectiva sobre GraphQL: su capacidad para utilizarse como un eficaz actor de puerta de enlace. El actor de puerta de enlace es una función o proceso creado cerca del cliente que inicia una solicitud de API. Este actor actúa como la puerta de enlace de API inicial que recibe y finaliza la solicitud. También puede ser efímero, de modo que se destruya una vez atendida la solicitud.

Además de que los desarrolladores y los equipos de operaciones priorizan la gestión de las API frente a las puertas de enlace de API, también detectamos el problema de la proliferación de puertas de enlace de API como consecuencia de la proliferación de API. Desde la perspectiva de un desarrollador, la principal preocupación es garantizar que la API funcione correctamente y responda a tiempo. Por otro lado, el equipo de operaciones se centra más en aspectos como la detección, la seguridad, la usabilidad y los controles de acceso. Dado que las puertas de enlace de API son actualmente un componente esencial de la infraestructura de API, quedó claro que la proliferación de API aumenta el despliegue de puertas de enlace de API, lo que provoca su proliferación.

El futuro de la arquitectura de las API debe evolucionar para dar cabida a la proliferación de API y, al mismo tiempo, simplificar el despliegue y las operaciones. La arquitectura propuesta representa el siguiente paso evolutivo que deben dar los patrones de diseño de las puertas de enlace de API. Aunque GraphQL no es un elemento central de la arquitectura ni un requisito, puede mejorar el patrón de actores de puerta de enlace.

Resumen

El ecosistema de gestión de API debe dejar atrás la gestión de puertas de enlace de API monolíticas y adoptar un enfoque más moderno para el diseño de sistemas. Esto dará lugar a un ecosistema de gestión de API más ágil y eficaz.

Proliferación de gateways de API: gestión de monolitos distribuidos

La proliferación de API, que ya supone un reto dentro de la economía de las API, también da lugar a la proliferación de gateways de API, una situación en la que la gestión de las API se ha vuelto incontrolable debido a la diversidad de tecnologías de los proveedores de gateways de API y a los equipos con criterios propios que los gestionan. Nos encontramos en un punto de inflexión en las arquitecturas de API, ya que el gateway de API tradicional (API-GW), una capa de software específica que actúa como punto de entrada para las llamadas a las API, ya no basta para gestionar la escala y la complejidad del ecosistema de API emergente.

La figura 1 ilustra cómo hemos pasado de gestionar la proliferación de API a gestionar la proliferación de puertas de enlace de API.

Figura 1: De la proliferación de API a la proliferación de puertas de enlace de API

El patrón de diseño anterior hace referencia a un plano de control centralizado, en el que las puertas de enlace de API conforman el plano de datos distribuido, tal como se muestra en la Figura 2.

Las puertas de enlace de API son un componente esencial de las arquitecturas de software modernas, ya que proporcionan un punto central de control y seguridad para las API. Sin embargo, a medida que ha aumentado el número de funciones que ofrecen, se han vuelto cada vez más complejas y difíciles de gestionar. En muchos casos, estas puertas de enlace han evolucionado hasta convertirse en sistemas monolíticos, con una amplia variedad de funcionalidades agrupadas en un único paquete.

Figura 2: Gestión de monolitos distribuidos

Aunque gestionar varias puertas de enlace puede parecer un diseño distribuido, en realidad dista mucho de ser una distribución auténtica. Esto se debe a que las puertas de enlace siguen estando estrechamente acopladas y comparten recursos y configuraciones difíciles de separar. Como resultado, muchas empresas acaban gestionando monolitos distribuidos y todos los desafíos que ello conlleva.

Arquitecturas de gateways de API heredadas

La figura 3 muestra la arquitectura de las puertas de enlace de API existentes. Las solicitudes de API procedentes del cliente se transmiten primero a través de una red compartida o dedicada y pasan por un cortafuegos antes de llegar a la puerta de enlace de API. A continuación, la puerta de enlace de API, que actúa como proxy inverso, reenvía el tráfico a la carga de trabajo de la API.

Figura 3: Arquitecturas tradicionales de puertas de enlace de API

La puerta de enlace de API (API-GW) heredada se convierte en un cuello de botella para la gestión de las API cuando se despliegan puertas de enlace de API en toda la empresa o cuando las cargas de trabajo de las API se trasladan operativamente entre regiones, zonas, varias nubes o al perímetro, al tiempo que se hace frente a la proliferación de API. Distintos equipos ponen en marcha varias API-GW sin un único punto de gestión y control empresarial. Si un servicio de API o un grupo de ellos se traslada a una infraestructura diferente (en la nube o de otro tipo), el equipo de operaciones debe disponer de un método para migrar todos los aspectos de la gestión de las API: registro, detección, autenticación, redes, seguridad y políticas de gobernanza, riesgo y cumplimiento (GRC).

Por tanto, la arquitectura representada en la Figura 3 no es escalable ni práctica a largo plazo, ya que, con el tiempo, obliga a gestionar monolitos distribuidos (Figura 2).

Hay dos problemas que convierten la puerta de enlace de API en un cuello de botella: (1) la proliferación de proveedores de puertas de enlace de API y (2) la necesidad de escalar sobre la marcha a medida que una empresa ejecuta más aplicaciones en más ubicaciones.

1. Proliferación de proveedores de gateways de API: Gestionar la proliferación de proveedores de gateways de API supone un reto humano, ya que puede resultar difícil convencer a todos los equipos para que adopten un único proveedor de gateways de API, y migrar a un nuevo proveedor puede ser una tarea engorrosa. Como consecuencia, las organizaciones acaban dedicando tiempo y recursos a gestionar varios proveedores de gateways. Aunque este problema puede abordarse, en la práctica quizá no sea del todo viable.
2. Escalado de aplicaciones: El escalado de aplicaciones supone un problema cuando la aplicación necesita admitir más usuarios en una única ubicación o debe implementarse en varias ubicaciones. Para ello, la aplicación debe escalar horizontal o verticalmente. Sin embargo, a medida que la aplicación escala, las puertas de enlace de API también deben hacerlo y, en algunos casos, deben implementarse en varias ubicaciones para permitir el escalado según los patrones de arquitectura actuales. Esto puede complicar la gestión operativa de las puertas de enlace de API.

Solución: un patrón de actor de puerta de enlace distribuida

La figura 4 muestra un patrón de actores de puerta de enlace distribuidos para abordar la proliferación de puertas de enlace de API. Aunque el patrón distribuido en sí no es nuevo, este documento lo formaliza en el contexto de las puertas de enlace de API. Los clientes inician la solicitud de API. Los actores de puerta de enlace distribuidos son efímeros y se crean bajo demanda lo más cerca posible del cliente. La capa de transporte de la API se encarga de enviar la solicitud de API desde el actor de puerta de enlace hasta la puerta de enlace de API simplificada, que a continuación dirige la solicitud a la carga de trabajo de API correspondiente. Aunque el uso de la compatibilidad con GraphQL en los actores distribuidos es más un detalle que un requisito para que este patrón funcione, sí permite ofrecer funcionalidades como la orquestación de servicios. Por tanto, en lugar de crear una nueva capa de orquestación de servicios, GraphQL podría proporcionar dicha funcionalidad.

Figura 4: Actores de puerta de enlace distribuida basados en GraphQL

Para aclararlo, el flujo del tráfico va de derecha a izquierda. Es decir, los clientes están a la derecha y son ellos quienes inician las solicitudes a la API, como se muestra en la Figura 5.

Figura 5: El tráfico fluye desde el cliente (derecha) hasta la carga de trabajo de la API (izquierda)

Está surgiendo un patrón de despliegue que utiliza actores de puerta de enlace para sustituir o reducir la dependencia excesiva de las puertas de enlace de API a la hora de gestionar las API dentro de una empresa y entre distintas empresas. Aunque GraphQL no es imprescindible para la arquitectura, su introducción llega en el momento oportuno, ya que el actor de puerta de enlace es el vehículo adecuado para ofrecer compatibilidad con GraphQL.

El papel de las puertas de enlace de API en la gestión de API

Para comprender mejor las puertas de enlace de API, es importante examinar primero los distintos componentes de la infraestructura moderna de gestión de API.

Infraestructura y funciones de gestión de API

La figura 6 ofrece una representación visual completa de las distintas funcionalidades y componentes esenciales para la gestión de API. Además de las puertas de enlace de API, necesarias para enrutar y gestionar el tráfico hacia los servicios de backend, existen otros componentes de infraestructura importantes. Entre ellos se pueden incluir soluciones de autenticación, limitación de solicitudes, almacenamiento en caché y malla de servicios, entre otras. Al incorporar estas funcionalidades, las organizaciones pueden controlar sus API, reforzar la seguridad y optimizar el rendimiento.

Figura 6: Funcionalidades de gestión de API e infraestructura

Características comunes de las puertas de enlace de API

Examinemos las características más conocidas y habituales de las puertas de enlace de API:

1. Enrutamiento: dirige las solicitudes al servicio de backend adecuado en función de la ruta o del contenido de la solicitud.
2. Autenticación y autorización: Autentica y autoriza las solicitudes desde un único punto de entrada, garantizando que solo los clientes autorizados puedan acceder a los servicios de backend.
3. Limitación de solicitudes: Limita la frecuencia con la que los clientes pueden realizar solicitudes a las API subyacentes, lo que evita un uso excesivo y protege los servicios de backend frente a sobrecargas.
4. Almacenamiento en caché: Almacena en caché las respuestas de las API subyacentes, lo que reduce el número de solicitudes que deben realizarse a los servicios de backend y mejora el rendimiento.
5. Traducción de protocolos: Traduce entre distintos protocolos, como HTTP y WebSockets, lo que permite a los clientes acceder a las API subyacentes mediante diferentes protocolos.
6. Equilibrado de carga: Distribuye las solicitudes entre varios servicios de backend, lo que mejora la escalabilidad y la fiabilidad.
7. Seguridad: Gestiona tareas de seguridad, como el cifrado y el descifrado, para garantizar que los datos se transmitan de forma segura.
8. Análisis y supervisión: Realiza un seguimiento y genera informes sobre las métricas de uso y la información de errores, lo que permite conocer cómo se utiliza el sistema y ayuda a identificar cuellos de botella en el rendimiento y errores.
9. Control de versiones: Gestiona el control de versiones de las API subyacentes, lo que permite a los clientes acceder a distintas versiones de la API en función de sus necesidades.
   
10. Descubrimiento de servicios: Descubre los servicios de backend disponibles y dirige dinámicamente las solicitudes hacia ellos, lo que permite un descubrimiento de servicios más dinámico y flexible.

Contexto: análisis de las puertas de enlace de API

Tras analizar las funcionalidades de la infraestructura de gestión de API, detectamos la necesidad de comprender mejor el papel de las puertas de enlace de API y explorar alternativas al actual diseño monolítico de estas.

Dado que el aumento del número de API ya está provocando una proliferación tanto de API como de puertas de enlace de API, cada vez más clientes son móviles o están muy distribuidos, y la infraestructura informática está disponible en todas partes, incluido el extremo de la red. Por tanto, necesitamos un enfoque que mejore la agilidad, la flexibilidad, la escalabilidad, el rendimiento y la seguridad del ecosistema de API.

Este nuevo enfoque requiere un diseño optimizado capaz de aprovechar al máximo las ventajas de una arquitectura verdaderamente distribuida.

Puertas de enlace de API

Analizamos más a fondo la funcionalidad y el alcance de una puerta de enlace de API para comprender mejor sus matices y limitaciones.

Una puerta de enlace de API es un componente fundamental de la infraestructura actual de gestión de API. En esencia, actúa como un proxy inverso, es decir, como intermediario entre los clientes y los servicios de backend, al tiempo que realiza diversas tareas sobre las solicitudes entrantes. Por ejemplo, puede autenticar, limitar la tasa de solicitudes, enrutar solicitudes, aplicar políticas de seguridad, supervisar y gestionar versiones antes de reenviar la solicitud al servicio de backend correspondiente. Una vez que el servicio de backend ha procesado la solicitud y devuelto una respuesta, la puerta de enlace de API puede realizar tareas como el almacenamiento en caché, la traducción de protocolos y el tratamiento de respuestas antes de reenviar la respuesta al cliente.

A medida que ha aumentado el número de API, las puertas de enlace de API han evolucionado para incorporar diversas funcionalidades nuevas más allá del enrutamiento básico, convirtiéndose en la práctica en sistemas monolíticos. Estas puertas de enlace ahora gestionan tareas como la autenticación y la limitación de solicitudes para mejorar el rendimiento y reducir la carga de los servicios de backend. Sin embargo, incluso con estas funcionalidades mejoradas, las puertas de enlace de API siguen siendo un único punto de acceso al servicio de backend, lo que puede plantear dificultades en entornos altamente distribuidos.

En particular, el auge de las infraestructuras en la nube, multinube híbrida y perimetrales ha dificultado el mantenimiento de la agilidad, la seguridad y la facilidad de gestión mediante un enfoque basado en una puerta de enlace de API. Dado que los clientes, los dispositivos y las cargas de trabajo de las aplicaciones pueden estar distribuidos entre una gran variedad de ubicaciones, es posible que una puerta de enlace de API no sea la opción más adecuada para proporcionar el nivel necesario de arquitectura compatible con entornos perimetrales.

Desafíos de las puertas de enlace de API

Dado que se encargan de una amplia variedad de tareas y deben integrarse con múltiples sistemas, las puertas de enlace de API suelen ser difíciles de implementar y gestionar. Aunque la gestión de las puertas de enlace de API puede resultar compleja, es una tarea fundamental para garantizar la disponibilidad, la seguridad y la escalabilidad de una API. Las empresas suelen utilizar herramientas especializadas, como plataformas de gestión de API, para gestionar y supervisar sus puertas de enlace de API de forma más eficaz.

La siguiente lista no es exhaustiva, pero algunos de los elementos que contribuyen a la complejidad de las puertas de enlace de API son:

1. Gestión de la configuración: las puertas de enlace de API suelen disponer de una amplia variedad de opciones y ajustes de configuración que deben gestionarse y mantenerse, como las reglas de enrutamiento, la limitación de solicitudes y los ajustes de seguridad. Gestionar estos ajustes puede resultar complejo y requerir mucho tiempo, especialmente a medida que aumenta el número de API y clientes subyacentes.
2. Integración con otros sistemas: Las puertas de enlace deben integrarse con una amplia variedad de sistemas, como sistemas de autenticación y autorización, balanceadores de carga y bases de datos. Esto puede resultar complejo, especialmente cuando los sistemas subyacentes no están bien integrados o cuando la puerta de enlace de API debe gestionar varios protocolos o formatos de datos. La situación se complica aún más cuando una empresa cuenta con varias implementaciones de puertas de enlace de API de distintos proveedores.
3. Escalabilidad y disponibilidad: las puertas de enlace de API deben ser capaces de gestionar un gran número de solicitudes y garantizar una alta disponibilidad, algo que puede resultar complejo, especialmente cuando se trabaja con un gran número de servicios de backend y clientes.
4. Seguridad: Como componente crítico de la seguridad de las API, las puertas de enlace de API deben configurarse y gestionarse para garantizar la protección de los datos confidenciales y el control del acceso. Esto puede resultar complejo y requiere una supervisión y gestión continuas.
5. Control de versiones: A medida que aumenta el número de API subyacentes y de clientes, puede resultar cada vez más difícil gestionar las distintas versiones de la API y garantizar que los clientes accedan a la versión correcta.
6. Supervisión y resolución de problemas: las puertas de enlace de API pueden recopilar y generar grandes cantidades de datos. En una gran empresa, estas puertas de enlace pueden estar distribuidas en numerosas ubicaciones, lo que dificulta correlacionar los eventos que afectan al estado general de la aplicación y resolver los problemas.

Proliferación de gateways de API

La proliferación de gateways de API se refiere a la multiplicación de gateways de API independientes dentro de una organización. A menudo, los distintos equipos o unidades de negocio crean sus propias API, lo que puede dar lugar a la creación de varios gateways independientes para gestionar estas API. Los distintos equipos también pueden utilizar gateways de API de diferentes proveedores o soluciones para gestionar distintos tipos de API.

Esto da lugar al despliegue de múltiples puertas de enlace de API, cada una con un conjunto de funcionalidades diferente.

La proliferación de gateways de API plantea varios retos adicionales:

1. Escalado de la gestión de las puertas de enlace de API: Disponer de varias puertas de enlace de API independientes puede dificultar su gestión y mantenimiento, especialmente a medida que aumenta el número de API y clientes subyacentes.
2. Ineficiencias en el tráfico este-oeste: La existencia de varias puertas de enlace puede hacer que las solicitudes tengan que pasar por varias de ellas, lo que aumenta la latencia y reduce el rendimiento.
3. Uniformidad de las políticas de seguridad: Gestionar varias puertas de enlace puede resultar complicado y dar lugar a políticas de seguridad incoherentes, lo que dificulta garantizar la protección de los datos confidenciales y el control del acceso.
4. Gobernanza estandarizada: Con varias puertas de enlace, puede resultar difícil garantizar que todas las API estén correctamente gobernadas y cumplan las normas y las mejores prácticas.
5. Aumento de los costes: Disponer de varias puertas de enlace puede aumentar los costes de infraestructura, recursos de desarrollo y mantenimiento.
6. Mayores dificultades de integración: Disponer de varias puertas de enlace dificulta la integración con otros sistemas y tecnologías, como otras bases de datos, almacenes de datos y herramientas de análisis de datos.

Las empresas deben procurar centralizar la gestión y la gobernanza de sus API y utilizar un único tipo de puerta de enlace de API. Aunque esto mitigará los problemas mencionados anteriormente derivados de la proliferación de puertas de enlace de API, adoptar una estrategia homogénea para estas puertas de enlace no es en absoluto sencillo.

Desafíos de la estandarización de las puertas de enlace de API en una empresa

A medida que las empresas crecen de forma orgánica o mediante adquisiciones, los equipos internos vinculados a unidades de negocio específicas discreparán entre sí a la hora de seleccionar una tecnología o un proveedor de puertas de enlace de API. Algunos de los motivos son los siguientes:

• Tecnología: Los distintos equipos o unidades de negocio utilizan diferentes pilas tecnológicas o prefieren distintas soluciones de puerta de enlace de API, lo que dificulta la estandarización en un único tipo de puerta de enlace.
• Sistemas heredados: Algunos equipos cuentan con sistemas existentes que se crearon utilizando otro tipo de puerta de enlace de API, y sería difícil sustituirlos por una nueva, especialmente si todavía están en uso.
• Personalización: Algunos equipos personalizarán sus puertas de enlace de API actuales para satisfacer requisitos específicos y tendrán dificultades para reproducir estas personalizaciones en una nueva puerta de enlace.
• Coste de sustitución: Sustituir las puertas de enlace de API existentes por una nueva puerta de enlace estandarizada puede resultar costoso, tanto en términos de desarrollo como de mantenimiento.
• Formación de desarrolladores: Los equipos tienen distintos niveles de experiencia y puede que necesiten familiarizarse con una nueva tecnología de puerta de enlace de otro proveedor o recibir formación sobre ella, un proceso que puede requerir mucho tiempo y resultar costoso.
• Recursos limitados: Las organizaciones disponen de recursos limitados en cuanto a desarrolladores, presupuesto y tiempo para realizar el cambio, lo que dificulta la implementación de una nueva puerta de enlace.
• Dependencias de las aplicaciones: Los distintos equipos o unidades de negocio tienen diferentes dependencias de sus gateways actuales, como integraciones con sistemas específicos u otras integraciones personalizadas, lo que dificulta la migración a uno nuevo.
• Soluciones de terceros: Los equipos que utilizan soluciones de terceros integradas con la puerta de enlace tendrán dificultades para migrar a una nueva solución que no sea compatible con dichas soluciones de terceros.

Por tanto, si una aplicación existente cuenta con un equipo consolidado y con criterios bien definidos, este no querrá cambiar a un patrón de despliegue diferente para evitar interrupciones en el servicio.

Por tanto, podemos concluir que se necesita un nuevo enfoque que tenga en cuenta las múltiples limitaciones de la infraestructura de API existente y que destaque la proliferación de puertas de enlace de API como uno de los aspectos más importantes.

Consideraciones de diseño

La siguiente no es una lista exhaustiva, pero resume algunas de las consideraciones generales de diseño que creemos que deberían tenerse en cuenta al desarrollar la solución:

1. Coexistir con las implementaciones actuales: A medida que las organizaciones se esfuerzan por mantenerse al día con un panorama tecnológico en constante evolución, es habitual que las empresas cuenten con una amplia variedad de implementaciones de puertas de enlace de API. No es viable sustituir por completo la infraestructura de API existente, ya que esto podría interrumpir operaciones empresariales críticas. Por tanto, cualquier nueva implementación debe diseñarse de forma que pueda coexistir con la arquitectura actualmente desplegada.
2. Estandarizar las funciones de la puerta de enlace de API: El objetivo principal de la estrategia de API de una empresa debe ser estandarizar las funciones de sus puertas de enlace de API, lo que puede resultar complicado debido a la diversidad de API y a las distintas necesidades de las diferentes unidades de negocio. No obstante, esta estandarización es fundamental para crear una infraestructura estable y segura que pueda respaldar la transformación digital de la organización.
3. Aprovechar los despliegues en el edge: La infraestructura del edge no solo tiene el potencial de aumentar exponencialmente el número de API, sino que también ofrece a las empresas la oportunidad de acercar sus componentes de gateway al edge. Esto es posible porque la misma infraestructura utilizada para crear API también puede emplearse para crear componentes de gateway distribuidos. Por lo tanto, la solución debe aprovechar al máximo la proximidad de la infraestructura del edge a los clientes que inician la solicitud de API.
4. Independiente del transporte: Un aspecto importante que debe tenerse en cuenta al implementar una arquitectura de actores de puerta de enlace distribuidos es que no debe depender de ningún mecanismo de transporte específico. Tanto si una empresa desea utilizar redes IP tradicionales, redes superpuestas, VPN o una infraestructura de mensajería de baja latencia, la solución debe ser independiente del mecanismo de transporte. Esto ofrece una mayor flexibilidad y permite a las empresas elegir el mecanismo de transporte que mejor se adapte a sus necesidades y requisitos específicos.
5. Compatibilidad con GraphQL: GraphQL se está convirtiendo en una opción cada vez más popular para el desarrollo de API debido a sus numerosas ventajas frente a las API REST tradicionales. Una ventaja clave es su capacidad para proporcionar un acceso granular a los datos, lo que permite a los clientes especificar exactamente qué datos necesitan en una sola solicitud. Además, GraphQL puede simplificar el proceso de agregación de datos procedentes de varios servicios, lo que lo convierte en la arquitectura adecuada para la composición y orquestación de servicios. Esto puede reducir la sobrecarga de la red y mejorar el rendimiento, especialmente en un sistema distribuido en el que se utilizan varios servicios de API para atender una única solicitud. Por último, gracias a su esquema fuertemente tipado y a su lenguaje de consulta, GraphQL puede facilitar la detección de las API y simplificar el desarrollo de clientes.
6. La seguridad es un requisito básico: El principal objetivo de diseño es reforzar la postura de seguridad de las API de la empresa. La solución podría asumir algunas funciones, como autenticar y autorizar solicitudes de API, implementar controles de acceso y ofrecer protección frente a amenazas de seguridad habituales, como los ataques de scripts entre sitios (XSS) y de inyección SQL. La nueva solución no debe, bajo ninguna circunstancia, poner en riesgo el modelo de amenazas existente ni modificarlo de forma tan significativa que cambie la superficie de ataque. Al priorizar la seguridad como objetivo de diseño, la arquitectura debe proporcionar un entorno más seguro para la comunicación mediante API, reduciendo el riesgo de filtraciones de datos y otros incidentes de seguridad.

A partir de estas consideraciones de diseño, se pueden derivar requisitos específicos que hemos incorporado a nuestra solución de actores de puerta de enlace distribuida (DGA).

Actores de puerta de enlace distribuidos

Ahora que hemos analizado en profundidad las puertas de enlace de API, podemos explicar la solución de actores de puerta de enlace distribuidos.

Diseño de actores de puerta de enlace distribuidos

El patrón de diseño de actores de puerta de enlace distribuidos (DGA) se inspira en la computación en el borde y en los recursos informáticos disponibles cerca del cliente. La idea fundamental consiste en hiperdistribuir cada actor de puerta de enlace lo más cerca posible del cliente y hacer que exista únicamente mientras dure la transacción, para eliminarlo al finalizar.

Supuestos

Estos son algunos de los supuestos en los que se basa esta solución.

La computación en el borde se ha generalizado, y ahora podemos encontrar algún tipo de recurso informático disponible geográficamente más cerca del cliente. Los actores de la puerta de enlace pueden instanciarse en estos nodos de computación en el borde. El objetivo es disponer de una implementación en la que el DGA sea muy ligero y efímero, de modo que pueda instanciarse en cualquier recurso de computación en el borde.

El transporte de API es un componente crucial de la infraestructura, ya que implica establecer una red entre los actores de puerta de enlace y la puerta de enlace de API. El tipo de infraestructura necesaria depende del proveedor o de la empresa y puede variar. Por ejemplo, una gran nube pública puede utilizar su propia red troncal para ejecutar el transporte de API. Otra implementación podría consistir en un bus de mensajería de baja latencia sobre una red existente de gran ancho de banda y baja latencia dentro de un centro de datos empresarial.

Funciones de la puerta de enlace de API

En resumen, la puerta de enlace de API es básicamente un proxy inverso cuya función principal consiste en dirigir el tráfico HTTP a las cargas de trabajo de API correspondientes. Este enfoque tiene sentido cuando todas las API se encuentran en una misma ubicación, como una red local en las propias instalaciones o una nube privada virtual (VPC) dentro de una zona de disponibilidad. Sin embargo, a medida que aumenta el número de API, estas se trasladan a una infraestructura híbrida o simplemente adquieren movilidad, este diseño de puerta de enlace de API se vuelve ineficiente, complejo de gestionar y costoso.

Aunque puede haber distintos puntos de vista sobre cómo clasificar todas las funcionalidades descritas en la Figura 6, podemos convenir en que la infraestructura de gestión de API se ha convertido en un despliegue complejo de numerosos componentes que deben coordinarse cuidadosamente. 

Figura 7: Actores de la puerta de enlace distribuida basada en GraphQ-

La figura 7 relaciona las distintas características y funciones de la gestión de API de la figura 6 con la arquitectura de actores de puerta de enlace distribuida. Esta correspondencia muestra visualmente cómo cada característica y función se ajusta al enfoque DGA, y pone de relieve la perfecta integración de los componentes de gestión de API en la arquitectura.

Funciones centralizadas

La mayoría de las funcionalidades enumeradas anteriormente incluyen algún componente de gestión que puede centralizarse de forma lógica. Nuestro objetivo no es rediseñar la arquitectura del plano de gestión, sino eliminar determinadas funciones, si es posible.

Funciones principales de la puerta de enlace de API

Estas son funciones del plano de datos y, por tanto, lo más adecuado es implementarlas en la API y ubicarlas junto con las cargas de trabajo de las aplicaciones. Las puertas de enlace de API son un componente fundamental de la arquitectura moderna de microservicios y actúan como punto de entrada para todo el tráfico externo. Hemos clasificado sus funciones principales en enrutamiento, equilibrio de carga, enrutamiento dinámico, comprobaciones de estado, reintentos y mecanismos de respaldo.

Una puerta de enlace de API dirige las solicitudes entrantes al microservicio correspondiente, distribuye el tráfico entre varias instancias, admite el enrutamiento dinámico, supervisa el estado de los microservicios y sus instancias, reintenta las solicitudes fallidas y proporciona respuestas alternativas cuando un microservicio no está disponible o ha fallado. Otras funciones, como la autenticación, la autorización, la limitación de solicitudes, el almacenamiento en caché y el registro, pueden distribuirse en el perímetro o centralizarse, en función de los requisitos específicos del sistema.

Este enfoque modular permite una arquitectura más flexible y optimizada, y constituye el eje central de nuestra recomendación para simplificar, modernizar y escalar la infraestructura de API empresarial.

Combinado

Los proveedores suelen confundir erróneamente las pasarelas de API con la gestión de API, considerando esta última como parte de las funciones de una pasarela de API, pero en realidad son dos funciones distintas que deben tratarse por separado. Una pasarela de API se encarga de dirigir las solicitudes de los clientes a los servicios de backend, mientras que la gestión de API abarca un conjunto más amplio de funcionalidades, como el control de acceso, la limitación de solicitudes, el análisis y la gestión del portal para desarrolladores.

Aunque algunos proveedores pueden ofrecer funciones tanto de puerta de enlace de API como de gestión de API como parte de un único producto, es importante comprender las diferencias entre estas funciones y evaluarlas por separado en función de sus requisitos específicos. Combinar estas funciones puede generar confusión y limitar potencialmente la flexibilidad y la escalabilidad de la infraestructura de API de una organización. Esto también es fundamental para comprender nuestra postura sobre la distribución de la funcionalidad de la puerta de enlace de API.

Actor de la puerta de enlace – Funciones integradas

Las características que se enumeran aquí son funciones esenciales que deben estar integradas en la ruta de datos. En un patrón de puerta de enlace distribuida, algunas de las funciones integradas de la puerta de enlace de API también pasan a estar distribuidas. Entre estas funciones se incluyen el control de acceso, la limitación de solicitudes, la validación de solicitudes, el análisis de API, los informes de uso, la supervisión de la tasa de errores, las alertas y la gestión de eventos, la integración de la autenticación, la integración con terceros, la integración de la supervisión y el registro, el almacenamiento en caché en el perímetro y la compresión.

Trasladar estas funciones al patrón de puerta de enlace distribuida ofrece las siguientes ventajas:

• Menor carga en la puerta de enlace de API: Ayuda a reducir la carga en la puerta de enlace de API centralizada y a mejorar el rendimiento y la escalabilidad del sistema.
• Permite tiempos de respuesta más rápidos: Permite obtener tiempos de respuesta más rápidos y reducir la latencia al implementar estas funciones más cerca de los clientes. Al aprovechar el almacenamiento en caché de los datos y de la función, las puertas de enlace de API alojadas en el perímetro pueden responder rápidamente a las solicitudes entrantes.

Por ejemplo, el control de acceso, la limitación de solicitudes y la validación de peticiones pueden gestionarse mediante un actor de puerta de enlace perimetral, que se despliega más cerca de los clientes. Esto puede ayudar a reducir el número de solicitudes que debe gestionar la puerta de enlace de API centralizada, mejorando así su rendimiento y escalabilidad. Del mismo modo, las puertas de enlace perimetrales pueden encargarse del análisis de las API, los informes de uso, la supervisión de la tasa de errores, las alertas y los eventos, así como de la integración de la monitorización y el registro, recopilando y agregando datos de varios microservicios.

Actores de puerta de enlace: candidatos para GraphQL

Hoy en día, una funcionalidad importante que ofrecen las puertas de enlace de API es la composición y orquestación de servicios. Aunque esto puede llegar a ser bastante complejo, sería preocupante que la puerta de enlace de API simplificada no admitiera esta funcionalidad. Creemos que GraphQL puede ser un enfoque interesante para la composición de servicios, al actuar como una especie de middleware para las API existentes.

Gracias a su visibilidad de todas las API, la puerta de enlace de API se convierte en un lugar lógico para llevar a cabo la composición de servicios, lo que permite a los desarrolladores combinar las API situadas tras la puerta de enlace para mejorar la lógica de negocio sin necesidad de crear nuevos servicios, que pueden combinarse más fácilmente en una capa de composición de servicios.

La composición de servicios en GraphQL es posible gracias al uso de un esquema fuertemente tipado, que define la estructura de los datos disponibles para los clientes. Los clientes pueden utilizar este esquema para crear consultas que especifiquen exactamente los datos que necesitan, independientemente de los servicios o las fuentes que los proporcionen. Los resolvers, que son funciones que asignan las consultas a las fuentes de datos, se utilizan para recuperar datos del servicio o la fuente correspondiente. Sin embargo, aunque GraphQL promete una mayor seguridad, esta depende en última instancia del desarrollador que escribe el código.

Otras características y funciones

Aún quedan algunas funcionalidades que no se destacan en la Figura 6: Funcionalidades de gestión de API e infraestructura. Estas funcionalidades y funciones restantes son candidatas a trasladarse a funciones individuales de gestión y operaciones o del plano de datos.

Hemos optado deliberadamente por utilizar el término «actor» para evitar sugerir una implementación o tecnología de proveedor específica. La implementación del actor de la puerta de enlace podría basarse en métodos, funciones, procesos de trabajo, hilos y procesos, utilizando infraestructuras basadas en máquinas virtuales, contenedores, arquitecturas sin servidor u otros enfoques específicos de un proveedor.

Características y comportamiento del componente

El enfoque adoptado con la arquitectura de actores de puerta de enlace distribuida (DGA) simplifica las funciones de la puerta de enlace de API y traslada otras funcionalidades en línea al extremo o al plano de control.

Plano de control

Además de las funcionalidades de la puerta de enlace de API, la arquitectura DGA también recomienda identificar las funciones que podrían gestionarse mejor en el plano de control como un componente centralizado desde el punto de vista lógico, en lugar de implementarse dentro de una puerta de enlace de API monolítica. La gestión y el control de la infraestructura de API existente pueden ampliarse para incluir esta funcionalidad adicional.

Puerta de enlace de API simplificada

La simplificación de la puerta de enlace de API se convierte así en un ejercicio para definir un conjunto estándar de funciones básicas que todos los proveedores de puertas de enlace de API puedan gestionar mediante un conjunto común de parámetros de configuración.

Una empresa que desee llevar a cabo esta transformación podría implantar la arquitectura DGA aplicación por aplicación, sin alterar las implementaciones existentes ni tener que realizar una migración integral.

Actores de puerta de enlace distribuida

Un aspecto importante de la DGA es que cada actor de puerta de enlace es efímero, ya que solo se crea durante una sesión de API (es decir, mientras un cliente realiza una llamada a la API). 

Un actor de puerta de enlace distribuida puede ser más flexible, escalable y rentable que una puerta de enlace de API tradicional. En lugar de depender de varias puertas de enlace de API monolíticas de distintos proveedores para agregar y gestionar el tráfico de las API, el actor de puerta de enlace permite a los desarrolladores definir e implementar instancias de puerta de enlace individuales para cada API más cerca del extremo de la red. Las propias API podrían ofrecer un mayor control y más opciones de personalización para satisfacer sus necesidades específicas.

Este nuevo enfoque también ofrece una mayor escalabilidad, ya que los desarrolladores pueden poner en marcha fácilmente instancias del actor de puerta de enlace según sea necesario para gestionar el aumento del tráfico, sin tener que preocuparse por la sobrecarga que supone administrar una puerta de enlace centralizada de gran tamaño.

Además de sus ventajas técnicas, el actor de puerta de enlace también permite ahorrar costes frente a una puerta de enlace de API tradicional, ya que las empresas solo pagan por las instancias efímeras del actor de puerta de enlace que utilizan. Este modelo de despliegue puede abrir oportunidades para generar nuevas fuentes de ingresos.

Ubicación del actor de puerta de enlace

Al aprovechar una capa de transporte de API, los DGA desacoplan, en esencia, la ubicación de entrada de las API de la puerta de enlace de API. Los DGA pueden trasladarse al extremo de la red, es decir, más cerca del cliente que realiza la llamada a la API. Las API pueden terminar en los DGA y, a continuación, transportarse por cualquier medio. Esto difiere de la Figura 3: Arquitecturas tradicionales de puertas de enlace de API, donde el tráfico del cliente entra en un punto topológicamente adyacente a las puertas de enlace de API. 

Conclusión

Por tanto, nuestra intención ha sido proponer un enfoque independiente del proveedor y del modelo de implementación, ya que los distintos proveedores pueden disponer de propiedad intelectual propia para desarrollar estos componentes y alcanzar objetivos similares a los descritos.

En este artículo hemos resumido lo aprendido durante varios trimestres de investigación sobre la proliferación de API, las arquitecturas Edge 2.0, la economía de las API (https://www.f5.com/company/blog/inverting-the-api-is-the-digital-transformation-that-enterprises-need-to-participate-and-compete-in-an-api-economy) y las investigaciones sobre GraphQL. Aunque todavía no hay una conclusión definitiva respecto a la infraestructura de API heredada, creemos que es necesario adoptar un nuevo enfoque.

La mera promesa de liberar el valor de cada dispositivo o entidad individual a escala mundial constituye una razón de peso para explorar un nuevo enfoque. Debemos dejar atrás la infraestructura de API heredada actual porque, aunque parezca distribuida, en realidad es monolítica.

Proponemos un enfoque de actores de pasarela distribuidos basado en GraphQL e independiente de los proveedores para aprovechar todo el potencial de la emergente economía de las API.