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.
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.
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.
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.
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.
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:
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:
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:
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.
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:
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.
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:
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).
Ahora que hemos explorado completamente las puertas de enlace API, podemos explicar la solución de actor 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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.