Actores de puerta de enlace distribuida: Gestión de API en evolución
Tabla de contenido
Opinión de la Oficina del Director de Tecnología de F5
El equipo de la Oficina del CTO de F5 ha estado explorando el campo tecnológico relacionado con las API durante más de un año. Este último documento técnico es una continuación de nuestros esfuerzos por comprender el ecosistema API en constante evolución.
Los desafíos que detallamos con la gestión de la proliferación de API conducirán a desafíos con la proliferación de puertas de enlace de API, y los enfoques tradicionales para abordar estos desafíos no serán suficientes. Si bien las tecnologías gráficas como GraphQL son muy prometedoras para controlar la complejidad asociada con las API, son solo una parte de la solución ya que los desafíos van más allá de la conectividad, la seguridad y el enrutamiento. El enfoque correcto, basado en casi treinta años de experiencia en sistemas y aplicações de escalamiento, se basa en una arquitectura distribuida (no federada) que emplea GraphQL pero no depende únicamente de él.
En este artículo se explora un enfoque arquitectónico distribuido para abordar los desafíos de la proliferación de puertas de enlace de API.
Resumen
La economía digital será impulsada por las API, lo que nos dará una economía impulsada por API . A raíz del informe técnico sobre la proliferación de API , nuestro objetivo fue comprender cómo eliminar o aliviar el impacto de la proliferación de API. Si bien GraphQL parecía prometedor para reducir las ramificaciones de la proliferación de API, tiende a poner la responsabilidad en los desarrolladores de reescribir una gran parte de su base de código API. Sin embargo, un punto de vista emergente en torno a GraphQL es su capacidad para ser utilizado como un actor de puerta de enlace eficaz. El actor de puerta de enlace es una función o proceso creado cerca del cliente que inicia una solicitud de API. Este actor de puerta de enlace actúa como la puerta de enlace API inicial que finaliza la solicitud de API. También puede ser efímero, es decir, puede destruirse después de atender la solicitud.
Además de que los desarrolladores y los equipos de operaciones priorizan la gestión de API por sobre las puertas de enlace de API, también descubrimos el problema de la proliferación de las puertas de enlace de API debido a la proliferación de API. Desde la perspectiva de un desarrollador, la principal preocupación es garantizar que la API funcione correctamente y de manera oportuna. Por otro lado, el equipo de operaciones está más centrado en aspectos como el descubrimiento, la seguridad, la usabilidad y los controles de acceso. Dado que hoy en día las puertas de enlace de API son un componente fundamental de la infraestructura de API, se hizo evidente que la proliferación de API aumenta la implementación de puertas de enlace de API, lo que conduce a una proliferación de puertas de enlace de API.
El futuro de la arquitectura de API debe evolucionar para aceptar la proliferación de API y, al mismo tiempo, simplificar la implementación y las operaciones. La arquitectura propuesta es la próxima evolución de dónde deben estar los patrones de diseño de API Gateway. Si bien GraphQL no es central para la arquitectura ni una necesidad, tiene la capacidad de mejorar el patrón de actor de puerta de enlace.
resumen
El ecosistema de gestión de API debe alejarse de la gestión de monolitos de puertas de enlace de API y avanzar hacia un enfoque de diseño de sistemas más contemporáneo. Esto dará como resultado un ecosistema de gestión de API más ágil y eficaz.
Expansión de API Gateway: Gestión de monolitos distribuidos
La proliferación de API, que ya es un desafío dentro de la economía de las API, también da como resultado una proliferación de puertas de enlace de API , una situación en la que la gestión de las API se ha vuelto incontrolable debido a las diversas tecnologías de los proveedores de puertas de enlace de API y a los equipos con opiniones encontradas que las gestionan. Nos encontramos en un punto de inflexión en las arquitecturas de API, ya que la antigua puerta de enlace de API (API-GW), una capa de software dedicada que actúa como punto de entrada para las llamadas de API, ya no es suficiente 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.
El patrón de diseño anterior alude a un plano de control centralizado, donde las puertas de enlace API forman el plano de datos distribuidos, como se muestra en la Figura 2.
Las puertas de enlace API son un componente esencial de las arquitecturas de software modernas y proporcionan un punto central de control y seguridad para las API. Sin embargo, a medida que ha crecido el número de funciones ofrecidas por las puertas de enlace API, 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 gama de funcionalidades agrupadas en un único paquete.
Si bien la gestión de múltiples puertas de enlace puede parecer un diseño distribuido, la realidad es que no llega a ser una distribución verdadera. Esto se debe a que las puertas de enlace aún están estrechamente acopladas y comparten recursos y configuraciones que son difíciles de separar. Como resultado, muchas empresas terminan gestionando monolitos distribuidos y todos los desafíos que eso crea.
Arquitecturas de API Gateway heredadas
La figura 3 muestra la arquitectura de las puertas de enlace API existentes. Las solicitudes de API que se originan en el cliente se transmiten primero a través de una red compartida o dedicada, pasando por un firewall antes de llegar a la puerta de enlace de API. La puerta de enlace API, que actúa como un proxy inverso, luego reenvía el tráfico a la carga de trabajo de la API.
La API-GW heredada se convierte en un punto de estrangulamiento en la gestión de API cuando se implementan puertas de enlace de API en toda la empresa o cuando las cargas de trabajo de API se mueven operativamente entre regiones, zonas, múltiples nubes o hacia el borde mientras compiten con la proliferación de API. Diferentes equipos crean múltiples API-GW sin un único punto de control y gestión empresarial. Si un individuo o grupo de servicios de API se traslada a una infraestructura diferente (nube u otro tipo de infraestructura), el equipo de operaciones debe tener un método para migrar todos los aspectos de la gestión de API: registro, descubrimiento, autenticación, redes, seguridad y políticas de gobernanza, riesgo y cumplimiento (GRC).
Por lo tanto, la arquitectura representada en la Figura 3 no es escalable ni práctica a largo plazo, ya que con el tiempo conduce a la gestión de monolitos distribuidos (Figura 2).
Hay dos problemas que crean el punto de estrangulamiento de la puerta de enlace API: (1) la proliferación de proveedores de puertas de enlace API y (2) la escalabilidad a medida que avanza, cuando una empresa tiene más aplicações ejecutándose en más lugares.
- Expansión de proveedores de puertas de enlace API : Lidiar con la proliferación de proveedores de API Gateway es un desafío humano, ya que puede ser difícil convencer a todos los equipos de que adopten un único proveedor de API Gateway, y migrar a un nuevo proveedor puede ser una tarea engorrosa. Como resultado, las organizaciones terminan gastando tiempo y recursos en la gestión de múltiples proveedores de puertas de enlace. Aunque este problema se puede solucionar, quizá no sea totalmente factible en la realidad.
- Escalado de aplicação : Escalar aplicações es un problema cuando la aplicação necesita soportar más usuarios dentro de una sola ubicación o necesita implementarse en múltiples ubicaciones. Esto requiere que la aplicação se escale horizontal o verticalmente. Sin embargo, a medida que la aplicação escala, las puertas de enlace de API también deben escalar y, en algunos casos, es necesario implementarlas en múltiples ubicaciones para soportar el escalamiento según los patrones de arquitectura actuales. Esto puede hacer que la gestión de las puertas de enlace de API sea operativamente compleja.
Solución: Un patrón de actor de puerta de enlace distribuida
La figura 4 representa un patrón de actores de puerta de enlace distribuida para abordar la proliferación de puertas de enlace API. Si bien el patrón distribuido en sí no es nuevo, este documento lo formaliza dentro del contexto de las puertas de enlace de API. Los clientes inician la solicitud de API. Los actores de puerta de enlace distribuida son efímeros y se crean a pedido lo más cerca posible del cliente. Es responsabilidad de la capa de transporte de API enviar la solicitud de API desde el actor de la puerta de enlace a la puerta de enlace de API simplificada, que luego enruta la solicitud a la carga de trabajo de API adecuada. Si bien el uso del soporte de GraphQL en los actores distribuidos es más un detalle que un requisito para que este patrón funcione, permite soportar características como la orquestación de servicios. Entonces, en lugar de crear una nueva capa de orquestación de servicios, GraphQL podría proporcionar ese soporte.
Para aclarar, el patrón de tráfico es de derecha a izquierda. Es decir, los clientes están a la derecha y las solicitudes de API son iniciadas por el cliente como se muestra en la Figura 5.
Existe un patrón de implementación emergente que utiliza actores de puerta de enlace para reemplazar o reducir la dependencia excesiva de las puertas de enlace de API para administrar las API dentro y en toda la empresa. Si bien GraphQL no es necesario para la arquitectura, su introducción es oportuna ya que el actor de puerta de enlace es el vehículo adecuado para respaldar GraphQL.
Para obtener una comprensión más profunda del actor de puerta de enlace como una posible solución, es necesario examinar de cerca el estado actual de las infraestructuras de API, en particular las puertas de enlace de API. Esto se debe a que hemos identificado la proliferación de puertas de enlace como un factor importante que contribuye a los desafíos de operar y escalar las infraestructuras de API.
Para comprender mejor las puertas de enlace de API, es importante examinar primero los distintos componentes de la infraestructura de gestión de API moderna.
La Figura 6 ofrece una representación visual completa de las distintas características y componentes que son esenciales para la gestión de API. Además de las puertas de enlace API, que son necesarias para enrutar y administrar el tráfico a los servicios backend, hay otros componentes de infraestructura importantes. Estos pueden incluir soluciones para autenticación, limitación de velocidad, almacenamiento en caché y malla de servicios, entre otros. Al incorporar estas funciones, las organizaciones pueden lograr control sobre sus API, mejorar la seguridad y optimizar el rendimiento.
Examinemos las características comúnmente reconocidas y familiares de las puertas de enlace API:
- Enrutamiento : Envía las solicitudes al servicio backend apropiado según la ruta o el contenido de la solicitud.
- Autenticación y autorización : Autentica y autoriza solicitudes como un único punto de ingreso, lo que garantiza que solo los clientes autorizados puedan acceder a los servicios de backend.
- Limitación de velocidad : Limita la velocidad a la que los clientes pueden realizar solicitudes a las API subyacentes, lo que evita el uso excesivo y protege los servicios de backend contra la sobrecarga.
- Almacenamiento en caché : Almacena en caché las respuestas de las API subyacentes, lo que reduce la cantidad de solicitudes que deben realizarse a los servicios de backend y mejora el rendimiento.
- Traducción del protocolo : Se traduce entre diferentes protocolos, como HTTP y WebSockets, lo que permite a los clientes acceder a las API subyacentes utilizando diferentes protocolos.
- Equilibrio de carga : Distribuye solicitudes a múltiples servicios backend, mejorando la escalabilidad y la confiabilidad.
- Seguridad: Maneja tareas de seguridad, como cifrado y descifrado, para garantizar que los datos se transmitan de forma segura.
- Análisis y seguimiento: Realiza un seguimiento y genera informes sobre métricas de uso e información de errores, lo que proporciona visibilidad sobre cómo se utiliza el sistema y ayuda a identificar cuellos de botella y errores de rendimiento.
- Control de versiones : Maneja el control de versiones de las API subyacentes, lo que permite a los clientes acceder a diferentes versiones de la API según sus necesidades.
- Descubrimiento de servicios : Descubre los servicios backend disponibles y enruta dinámicamente las solicitudes hacia ellos, lo que permite un descubrimiento de servicios más dinámico y flexible.
Después de analizar las características de la infraestructura de gestión de API, identificamos la necesidad de comprender mejor el papel de las puertas de enlace de API y explorar alternativas al diseño monolítico actual de puertas de enlace de API.
Dado que el crecimiento de la cantidad de API ya está provocando una proliferación de API y de puertas de enlace de API, una cantidad cada vez mayor de clientes se están volviendo móviles o altamente distribuidos, y la infraestructura computacional se ha vuelto disponible en todas partes, incluso en el borde. Por lo tanto, necesitamos un enfoque que pueda mejorar la agilidad, la flexibilidad, la escalabilidad, el rendimiento y la seguridad del ecosistema API.
Este nuevo enfoque requiere un diseño optimizado capaz de aprovechar al máximo los beneficios de una arquitectura verdaderamente distribuida.
Analizamos más a fondo la funcionalidad y el alcance de una puerta de enlace API para descubrir sus matices y limitaciones.
Una puerta de enlace API es un componente fundamental de la infraestructura de gestión de API actual. En esencia, la puerta de enlace API es un proxy inverso; actúa como intermediario entre los clientes y los servicios backend mientras realiza una variedad de tareas en la solicitud entrante. Por ejemplo, la puerta de enlace puede autenticar, limitar la velocidad, solicitar ruta, aplicar políticas de seguridad, monitorear y aplicar versiones antes de reenviar la solicitud a un servicio backend apropiado. Una vez que el servicio backend ha procesado la solicitud y devuelto una respuesta, la puerta de enlace API puede realizar tareas como almacenamiento en caché, traducción de protocolo y manejo de respuesta antes de reenviar la respuesta al cliente.
A medida que ha crecido el número de API, las puertas de enlace de API han evolucionado para incluir una variedad de nuevas funcionalidades más allá del enrutamiento básico, convirtiéndose efectivamente en sistemas monolíticos. Estas puertas de enlace ahora gestionan tareas como la autenticación y la limitación de velocidad para mejorar el rendimiento y reducir la carga de los servicios de back-end. Sin embargo, incluso con esta funcionalidad mejorada, las puertas de enlace API siguen siendo un único punto de acceso al servicio backend, lo que puede presentar desafíos en entornos altamente distribuidos.
En particular, el auge de la nube, la nube híbrida y las infraestructuras de borde ha hecho que sea más difícil mantener la agilidad, la seguridad y la capacidad de administración con un enfoque de puerta de enlace de API. Dado que los clientes, los dispositivos y las cargas de trabajo de las aplicação pueden estar distribuidos en una amplia variedad de ubicaciones, es posible que una puerta de enlace de API no sea la más adecuada para brindar el nivel necesario de arquitectura compatible con el borde.
Dado que manejan una amplia gama de tareas y necesitan integrarse con múltiples sistemas, las puertas de enlace API suelen ser difíciles de implementar y administrar. Si bien la gestión de puertas de enlace API puede ser compleja, es fundamental para garantizar la disponibilidad, seguridad y 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 API de forma más eficaz.
La siguiente lista no es exhaustiva, pero algunos de los elementos que contribuyen a la complejidad de la puerta de enlace API incluyen:
- Gestión de configuración : Las puertas de enlace API suelen tener una amplia gama de opciones de configuración y configuraciones que deben administrarse y mantenerse, como reglas de enrutamiento, limitación de velocidad y configuraciones de seguridad. Administrar estas configuraciones puede ser complejo y llevar mucho tiempo, especialmente a medida que crece el número de API y clientes subyacentes.
- Integración con otros sistemas : Las puertas de enlace deben integrarse con una amplia gama de otros sistemas, como sistemas de autenticación y autorización, balanceadores de carga y bases de datos. Esto puede ser complejo, especialmente cuando los sistemas subyacentes no están bien integrados o cuando la puerta de enlace API necesita manejar múltiples protocolos o formatos de datos. Esto se vuelve más problemático cuando una empresa tiene múltiples implementaciones de API Gateway de múltiples proveedores.
- Escalabilidad y disponibilidad : Las puertas de enlace API deben poder gestionar grandes cantidades de solicitudes y garantizar una alta disponibilidad, lo que puede ser complejo de gestionar, especialmente cuando se trata con una gran cantidad de servicios y clientes de backend.
- Seguridad : Al ser un componente crítico de seguridad de API, las puertas de enlace de API de seguridad se deben configurar y administrar para garantizar que los datos confidenciales estén protegidos y el acceso esté controlado. Esto puede ser complejo y requiere seguimiento y gestión constantes.
- Control de versiones : A medida que crece el número de API y clientes subyacentes, puede resultar cada vez más difícil gestionar diferentes versiones de la API y garantizar que los clientes accedan a la versión correcta.
- Monitoreo y resolución de problemas : Las puertas de enlace API pueden recopilar y generar grandes cantidades de datos. En una empresa grande, las puertas de enlace pueden estar distribuidas en muchas ubicaciones, lo que dificulta la correlación de eventos que afectan la salud general de la aplicação y la solución de problemas.
Expansión de API Gateway
La proliferación de puertas de enlace API se refiere a la proliferación de múltiples puertas de enlace API independientes dentro de una organización. Diferentes equipos o unidades de negocios a menudo crean sus propias API, lo que puede llevar a la creación de múltiples puertas de enlace de API independientes para manejar estas diferentes API. Diferentes equipos también pueden utilizar puertas de enlace de API de diferentes proveedores o soluciones para gestionar distintos tipos de API.
Esto conduce a la implementación de múltiples puertas de enlace API, todas con distintos conjuntos de capacidades.
La proliferación de puertas de enlace API genera varios desafíos adicionales:
- Escalabilidad de la gestión de la puerta de enlace API : Tener múltiples puertas de enlace API independientes puede dificultar la administración y el mantenimiento de las puertas de enlace, especialmente a medida que crece el número de API y clientes subyacentes.
- Ineficiencias en el tráfico este-oeste : Tener varias puertas de enlace puede provocar que las solicitudes deban pasar por ellas, lo que aumenta la latencia y reduce el rendimiento.
- Uniformidad de las políticas de seguridad : Administrar múltiples puertas de enlace puede ser difícil y puede generar políticas de seguridad inconsistentes, lo que hace más difícil garantizar que los datos confidenciales estén protegidos y que el acceso esté controlado.
- Gobernanza estandarizada : Con múltiples puertas de enlace, puede resultar difícil garantizar que todas las API estén correctamente gobernadas y cumplan con los estándares y las mejores prácticas.
- Aumento del coste : Tener múltiples puertas de enlace puede generar mayores costos de infraestructura, recursos de desarrollo y mantenimiento.
- Desafíos de integración amplificados : Tener múltiples 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 esforzarse por centralizar la gestión y gobernanza de sus API y utilizar un único tipo de puerta de enlace API. Si bien esto aliviará los desafíos antes mencionados de la proliferación de puertas de enlace de API, una estrategia homogeneizada para las puertas de enlace de API no es nada sencilla.
Desafíos en la estandarización de las API Gateways en una empresa
A medida que las empresas crecen orgánicamente o mediante adquisiciones, los equipos internos alineados con unidades de negocios (BU) específicas estarán en desacuerdo entre sí al momento de seleccionar una tecnología o un proveedor de puerta de enlace de API. Algunas de las razones para esto incluyen las siguientes:
- Tecnología : Diferentes equipos o unidades de negocios tienen diferentes pilas de tecnología o prefieren diferentes soluciones de puerta de enlace API, lo que dificulta la estandarización en un único tipo de puerta de enlace.
- Sistemas heredados : Algunos equipos tienen sistemas existentes que se crearon utilizando un tipo diferente de puerta de enlace API, y sería difícil reemplazar estos sistemas con una nueva puerta de enlace, especialmente si todavía están en uso.
- Personalización : Algunos equipos personalizarán sus puertas de enlace API existentes para cumplir con requisitos específicos y les resultará difícil replicar estas personalizaciones en una nueva puerta de enlace.
- Costo de reemplazo : Reemplazar las puertas de enlace API existentes por una puerta de enlace nueva y estandarizada puede ser costoso, tanto en términos de desarrollo como de mantenimiento.
- Desarrolladores de formación : Los equipos varían en sus niveles de experiencia y pueden necesitar familiarizarse o recibir capacitación sobre una nueva tecnología de puerta de enlace de un proveedor diferente, un proceso que puede consumir mucho tiempo y ser costoso.
- Recursos limitados : Las organizaciones tienen recursos limitados en términos de desarrolladores, presupuesto y tiempo para realizar el cambio, lo que dificulta la implementación de una nueva puerta de enlace.
- Dependencias de la aplicação : Los distintos equipos o unidades de negocio tienen distintas dependencias de sus pasarelas existentes, como estar integrados con sistemas específicos u otras integraciones personalizadas, lo que dificulta el cambio a una nueva.
- Soluciones de terceros : A los equipos que utilizan soluciones de terceros que se integran con la puerta de enlace les resultará difícil migrar a una nueva solución que no admita estas soluciones de terceros.
Por lo tanto, si una aplicação existente cuenta con un equipo bien establecido y con opiniones firmes, el equipo no querrá cambiar a un patrón de implementación diferente para no causar interrupciones en su servicio.
Por lo tanto, podemos concluir que es necesario un nuevo enfoque que tenga en cuenta las múltiples limitaciones de la infraestructura API existente y destaque la proliferación de puertas de enlace API como una de las consideraciones más importantes.
Consideraciones de diseño
La siguiente no es una lista exhaustiva, pero resume algunas de las consideraciones de diseño de alto nivel que creemos que deben incorporarse al construir la solución:
- Coexistir con las implementaciones actuales : A medida que las organizaciones se esfuerzan por mantenerse al día con el panorama tecnológico en constante cambio, es común que las empresas tengan una gama diversa de implementaciones de API Gateway. No es posible trasladar la infraestructura API existente, ya que esto puede interrumpir operaciones comerciales críticas. Por lo tanto, cualquier nueva implementación debe diseñarse de manera que pueda coexistir con la arquitectura implementada actualmente.
- Estandarizar las funciones de la API Gateway : El objetivo principal de la estrategia de API de una empresa debe ser estandarizar la funcionalidad de su puerta de enlace de API, lo que puede ser una tarea desafiante debido a la amplia gama de API y las distintas necesidades de las diferentes unidades de negocios. Sin embargo, esta estandarización es crucial para crear una infraestructura estable y segura que pueda soportar la transformación digital de la organización.
- Aproveche las implementaciones de borde : La infraestructura de borde no solo tiene el potencial de aumentar exponencialmente la cantidad de API, sino que también brinda una oportunidad para que las empresas acerquen sus actores de puerta de enlace al borde. Esto es posible porque la misma infraestructura utilizada para crear API también se puede utilizar para crear actores de puerta de enlace distribuidos. Por lo tanto, la solución debe aprovechar al máximo la proximidad de la infraestructura de borde a los clientes que inician la solicitud de API.
- Transporte agnóstico : Una consideración importante para la implementación de la arquitectura de actores de puerta de enlace distribuida es que no debe depender de ningún mecanismo de transporte específico. Ya sea que una empresa desee utilizar redes IP tradicionales, redes superpuestas, VPN o infraestructura de mensajería de baja latencia, la solución debe ser independiente del mecanismo de transporte. Esto permite una mayor flexibilidad y permite a las empresas elegir el mecanismo de transporte que mejor se adapte a sus necesidades y requisitos específicos.
- 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 sobre las API REST tradicionales. Una ventaja clave es su capacidad de proporcionar acceso detallado a los datos, permitiendo a los clientes especificar exactamente qué datos necesitan en una sola solicitud. Además, GraphQL puede simplificar el proceso de agregación de datos de múltiples servicios, lo que lo convierte en la arquitectura adecuada para realizar la componibilidad y orquestación de servicios. Esto puede reducir la sobrecarga de la red y mejorar el rendimiento, especialmente en un sistema distribuido donde se utilizan múltiples servicios de API para satisfacer una sola solicitud. Finalmente, con su esquema fuertemente tipado y su lenguaje de consulta, GraphQL puede mejorar la capacidad de descubrimiento de la API y permitir un desarrollo más sencillo del cliente.
- La seguridad es una cuestión de seguridad : El objetivo principal del diseño es que sea complementario a la postura de seguridad de la API de la empresa. La solución podría incluir algunas de las funciones, como la capacidad de autenticar y autorizar solicitudes de API, implementar controles de acceso y proteger contra amenazas de seguridad comunes como ataques de secuencias de comandos entre sitios (XSS) e inyección SQL. Bajo ninguna circunstancia la nueva solución debe comprometer el modelo de amenaza existente o cambiarlo tan significativamente que cambie la superficie de ataque. Al priorizar la seguridad como un objetivo de diseño, la arquitectura debe proporcionar un entorno más seguro para la comunicación API, reduciendo el riesgo de violaciones de datos y otros incidentes de seguridad.
Se pueden derivar requisitos específicos en función de estas consideraciones de diseño, que hemos incorporado a nuestra solución de actores de puerta de enlace distribuida (DGA).
Actores de puerta de enlace distribuida
Ahora que hemos explorado completamente las puertas de enlace API, podemos explicar la solución de actor de puerta de enlace distribuida.
Diseño de actores de puerta de enlace distribuida
El patrón de diseño de actores de puerta de enlace distribuida (DGA) se inspira en la edge computing y la computación disponible cerca de un cliente. El quid de la idea radica en hiperdistribuir cada actor de puerta de enlace lo más cerca posible del cliente y hacer que el actor de puerta de enlace exista solo mientras dure la transacción antes de que se liquide al final.
Suposiciones
A continuación se presentan algunos de los supuestos subyacentes de esta solución.
La computación de borde se ha vuelto más omnipresente y ahora podemos encontrar algún tipo de computación que esté geográficamente disponible más cerca del cliente. Los actores de puerta de enlace se pueden instanciar en estos nodos de cómputo de borde. La intención es tener una implementación donde el DGA sea muy liviano y efímero para que pueda instanciarse en cualquier cómputo de borde.
El transporte de API es un componente crucial de la infraestructura, ya que implica establecer una red entre los actores de la puerta de enlace y la puerta de enlace de API. El tipo de infraestructura requerida depende del proveedor o la empresa y puede variar. Por ejemplo, una nube pública grande puede utilizar su propia red troncal para ejecutar el transporte de API. Otra implementación podría ser un bus de mensajería de baja latencia colocado sobre una red existente de alto ancho de banda y baja latencia dentro de un centro de datos empresarial.
Funciones de API Gateway
Para reiterar, la puerta de enlace API es esencialmente un proxy inverso cuya función principal es enrutar el tráfico HTTP a las cargas de trabajo API adecuadas. Este enfoque tiene sentido cuando todas las API están ubicadas juntas, como dentro de una red local o dentro de una nube privada virtual (VPC) dentro de una zona de disponibilidad. Pero a medida que el número de API aumenta, se traslada a una infraestructura híbrida o simplemente se vuelve móvil, este enfoque de diseño de puerta de enlace de API se vuelve ineficiente, complejo de operar y costoso.
Si bien puede haber diferentes puntos de vista sobre cómo clasificar todas las características descritas en la Figura 6, podemos estar de acuerdo en que la infraestructura de gestión de API se ha convertido en una implementación compleja de muchos componentes que deben orquestarse cuidadosamente.
La Figura 7 mapea las diversas características y funciones de la gestión de API de la Figura 6 a la arquitectura de actores de puerta de enlace distribuida. Este mapeo ilustra visualmente cómo cada característica y función está alineada con el enfoque DGA, resaltando la integración perfecta de los componentes de administración de API dentro de la arquitectura.
Funciones centralizadas
La mayoría de las características enumeradas anteriormente tienen algún componente de gestión que puede centralizarse lógicamente. Nuestro objetivo no es rediseñar el plano de gestión sino, si es posible, eliminar ciertas funciones.
Funciones principales de API Gateway
Estas son funciones del plano de datos y, por lo tanto, se implementan mejor en la API y junto con las cargas de trabajo de la aplicação . Las puertas de enlace API son un componente crucial de la arquitectura de microservicios moderna que sirve como punto de entrada para todo el tráfico externo. Clasificamos sus funciones principales para incluir enrutamiento, equilibrio de carga, enrutamiento dinámico, verificación de estado, reintentos y alternativas.
Una puerta de enlace API dirige las solicitudes entrantes al microservicio apropiado, distribuye el tráfico entre múltiples instancias, admite el enrutamiento dinámico, monitorea el estado de los microservicios y sus instancias, reintenta las solicitudes fallidas y proporciona respuestas de respaldo cuando un microservicio no está disponible o ha fallado. Otras funciones como autenticación, autorización, limitación de velocidad, almacenamiento en caché y registro se pueden distribuir al borde o a funciones centralizadas según los requisitos específicos del sistema.
Este enfoque modular permite una arquitectura más flexible y optimizada y es la base de nuestra recomendación para simplificar, modernizar y escalar la infraestructura de API empresarial.
Combinado
Los proveedores a menudo confunden erróneamente API gateway y API management como parte de la función de API gateway, pero en realidad son dos funciones distintas que deben tratarse por separado. Una puerta de enlace API es responsable de enrutar las solicitudes de los clientes a los servicios backend, mientras que la gestión de API abarca un conjunto más amplio de funciones, como control de acceso, limitación de velocidad, análisis y gestión del portal para desarrolladores.
Si bien algunos proveedores pueden ofrecer funciones de API gateway y de administración de API como parte de un solo producto, es importante comprender las diferencias entre estas funciones y evaluarlas por separado en función de sus requisitos específicos. La combinación de estas funciones puede generar confusión y potencialmente limitar la flexibilidad y escalabilidad de la infraestructura de API de una organización. Esto también es fundamental para comprender nuestra posición sobre la distribución de la funcionalidad de la puerta de enlace API.
Actor de puerta de enlace: Funciones en línea
Las características enumeradas aquí son funciones principales que deben estar en línea con la ruta de datos. En un patrón de puerta de enlace distribuida, algunas de las funciones en línea de la puerta de enlace API también se distribuyen. Estas funciones incluyen control de acceso, limitación de velocidad, validación de solicitudes, análisis de API, informes de uso, monitoreo de tasa de errores, alertas y eventos, integración de autenticación, integración de terceros, integración de monitoreo y registro, almacenamiento en caché de borde y compresión.
Trasladar estas funciones al patrón de puerta de enlace distribuida tiene los siguientes beneficios:
- Carga reducida en la puerta de enlace API : Ayuda a reducir la carga en la puerta de enlace API centralizada y mejora el rendimiento y la escalabilidad del sistema.
- Habilite tiempos de respuesta más rápidos : Habilite tiempos de respuesta más rápidos y una latencia reducida implementando estas funciones más cerca de los clientes. Al aprovechar el almacenamiento en caché de los datos y la función, las puertas de enlace de API alojadas en el borde pueden responder rápidamente a las solicitudes entrantes.
Por ejemplo, el control de acceso, la limitación de velocidad y la validación de solicitudes pueden ser manejados por un actor de puerta de enlace de borde, que se implementa más cerca de los clientes. Esto puede ayudar a reducir la cantidad de solicitudes que debe gestionar la API centralizada, mejorando su rendimiento y escalabilidad. De manera similar, los análisis de API, los informes de uso, el monitoreo de la tasa de errores, las alertas y eventos y la integración del monitoreo y el registro pueden ser manejados por puertas de enlace de borde, que pueden recolectar y agregar datos de múltiples microservicios.
Actores de puerta de enlace: candidatos GraphQL
Hoy en día, una capacidad importante que admiten las puertas de enlace API es la composición y orquestación de servicios. Si bien esto puede volverse bastante complejo, se convertiría en un problema si esta función no fuera compatible con la puerta de enlace API simplificada. Creemos que GraphQL puede ser un enfoque interesante para la composición de servicios, actuando como una especie de middleware para las API existentes.
Debido a su visibilidad de todas las API, la puerta de enlace de API se convierte en un lugar lógico para realizar la composición de servicios, lo que permite a los desarrolladores combinar las API detrás de la puerta de enlace para mejorar la lógica empresarial sin necesidad de escribir nuevos servicios que se puedan combinar 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 forma de los datos disponibles para los clientes. Los clientes pueden utilizar este esquema para construir consultas que especifiquen los datos exactos que necesitan, independientemente de qué servicios o fuentes los proporcionen. Los solucionadores, que son funciones que asignan consultas a fuentes de datos, se utilizan para recuperar datos del servicio o fuente apropiados. Sin embargo, aunque GraphQL promete una mayor seguridad, su calidad depende del desarrollador que escribe el código.
Otras características y funciones
Aún quedan algunas características restantes que no se destacan en la Figura 6: Funciones de infraestructura y gestión de API . Las características y funciones restantes son candidatas que se pueden trasladar a funciones de gestión y operaciones individuales o del plano de datos.
Elegimos deliberadamente utilizar el término “actor” para evitar sugerir una implementación o tecnología de proveedor específica. La implementación del actor de puerta de enlace podría basarse en métodos, funciones, trabajadores, subprocesos y procesos, implementados mediante infraestructuras basadas en máquinas virtuales, contenedores, 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 API y mueve otras funciones en línea al borde o al plano de control.
Plano de control
Además de las características de la puerta de enlace API, la arquitectura DGA también recomienda identificar funciones que podrían servirse mejor en el plano de control como un componente lógicamente centralizado en lugar de implementarse dentro de una puerta de enlace API monolítica. La gestión y el control de la infraestructura API que ya existe se pueden ampliar y expandir para incluir esta funcionalidad adicional.
Puerta de enlace API simplificada
De este modo, la simplificación de la puerta de enlace API se convierte en un ejercicio para derivar un conjunto estándar de funciones básicas que todos los proveedores de puertas de enlace API pueden gestionar a través de un conjunto común de parámetros de configuración.
Una empresa que desee realizar esta transformación podría implementar la arquitectura DGA una aplicação a la vez, sin alterar las implementaciones existentes y sin necesidad de una operación minuciosa.
Actores de puerta de enlace distribuida
Un aspecto importante de DGA es que cada actor de puerta de enlace es efímero y se instancia solo mientras dura una sesión de API (es decir, un cliente realiza una llamada de API).
Un actor de puerta de enlace distribuida puede ser más flexible, escalable y rentable que la puerta de enlace API tradicional. En lugar de depender de múltiples puertas de enlace de API monolíticas de diferentes proveedores para agregar y gestionar el tráfico de API, el actor de puerta de enlace permite a los desarrolladores especificar e implementar instancias de puerta de enlace individuales para cada API más cerca del borde de la red. Las propias API podrían proporcionar un mayor control y personalización para sus necesidades específicas.
Este nuevo enfoque también permite una mayor escalabilidad, ya que los desarrolladores pueden activar fácilmente las instancias del actor de puerta de enlace según sea necesario para manejar el aumento de tráfico sin preocuparse por los costos generales de administrar una puerta de enlace grande y centralizada.
Además de sus beneficios técnicos, el actor de puerta de enlace también ofrece ahorros de costos en comparación con la puerta de enlace API tradicional, al permitir que las empresas solo paguen por las instancias de actor de puerta de enlace efímeras que utilizan. Este modelo de implementación puede abrir oportunidades para modelos de ingresos adicionales.
Ubicación de los actores de acceso
Al aprovechar una capa de transporte de API, los DGA esencialmente desacoplan la ubicación de ingreso de la API de la puerta de enlace de API. Los DGA se pueden mover al borde, es decir, más cerca del cliente que realiza la llamada a la API. Las API pueden terminar en los DGA y luego ser transportadas por cualquier medio. Esto es diferente de la Figura 3: Arquitecturas de puerta de enlace de API heredadas donde el tráfico del cliente ingresa topológicamente adyacente a las puertas de enlace de API.
CONCLUSIÓN
Nuestra intención, por tanto, ha sido proponer un enfoque independiente del proveedor y de la implementación, ya que diferentes proveedores pueden tener su propia propiedad intelectual para construir estos componentes para lograr objetivos similares a los descritos.
En este documento hemos resumido nuestros aprendizajes de múltiples fuentes de investigación sobre la proliferación de API , las arquitecturas Edge 2.0 , la economía de API y las investigaciones sobre GraphQL. Si bien el jurado aún no ha emitido un dictamen respecto de la infraestructura de API heredada, creemos que es necesario adoptar un nuevo enfoque.
La sola promesa de liberar valor dentro de cada dispositivo o entidad individual a nivel global proporciona una razón suficientemente fuerte para explorar un nuevo enfoque. Hoy en día, debemos alejarnos de la infraestructura API heredada porque, si bien parece distribuida, en realidad es monolítica.
Proponemos el enfoque de actor de puerta de enlace distribuido basado en GraphQL como una forma independiente del proveedor para liberar todo el potencial de la economía API emergente.