API Gateway, ¿qué patrón utilizar para implantarlo?

En los últimos años las diferentes soluciones y productos de API Management han evolucionado notablemente desde una etapa inicial en la que se ofrecía un proxy inverso con capacidades de securización, hasta la actualidad en la que la mayoría de proveedores ofertan una plataforma que gestiona diferentes estados del ciclo de vida de las APIs y de sus consumidores.

La incorporación por parte de los clientes de este tipo de plataformas a su stack tecnológico provocó la aparición de nuevos proveedores que ofertan estos productos, pero incorporando en ellos nuevos servicios y funcionalidades. Este hecho provocó un aumento de la competencia y la diversidad del mercado actual.

Algunas de las principales tendencias y retos a los que se enfrentan estos productos son:

• La integración de estas plataformas de administración en la cadena de desarrollo y herramientas Devops.
• La incorporación de nuevas capacidades para el desarrollo seguro de aplicaciones.
• La adaptación a las nuevas tendencias de desarrollo como es la expansión de arquitecturas de microservicios y plataformas IPaaS.

Es en este último punto es en el que se engloba este artículo, ya que una de las necesidades más acuciantes a la hora de implantar estos productos es la flexibilidad para exponer funcionalidades independientemente de dónde se encuentren dichas funcionalidades.

Esta necesidad radica en que los clientes buscan utilizar una plataforma de gestión de APIs única para servicios que pueden estar: dentro de la organización en su CPD; en la nube privada o nube pública de los distintos proveedores AWS, GCP o Azure, porque utilizan las capacidades de cada uno de ellos en función del caso de uso; y todo esto sin penalizar la latencia.

En este sentido los distintos proveedores de API Management están trabajando en la posibilidad de implantar el API Gateway de sus productos de manera flexible para dar respuesta a este requisito.

En este post se muestran los distintos patrones de implantación del API Gateway con los pros y contras de cada uno de ellos.

Patrones de API Gateway

API Gateway centralizado

Es el patrón más habitual y extendido en el cual se implanta un cluster de API Gateways que manejan todas las peticiones de las APIs, tanto internas como externas. Este cluster se escala horizontalmente y la carga es distribuida por todos los nodos de dicho cluster.

Este tipo de implantación agrega un salto adicional a la comunicación entre servicios, ya que para llamarse entre ellos tienen que pasar por el API Gateway central. Esto puede llegar a ser un problema a nivel de latencia de red y tiene como inconveniente añadido que se está forzando a salir de la red interna a las comunicaciones entre microservicios. Si la cantidad de microservicios expuestos y el consumo de los mismos crece desmesuradamente el cluster central del API Gateway debe escalarse horizontalmente para dar servicio y puede ser difícil de gestionar.

En caso de optar por este patrón, el cluster de API gateways se puede implantar en el CPD de la organización o en la nube teniendo para cada caso lo siguientes pros y contras.

API Gateway centralizado on-premise

Se caracteriza por ser un cluster de API Gateways que gestiona todo el tráfico, tanto interno como externo, implantado on-premise. Dicha implantación on-premise puede ser dentro de la organización en su CPD o en la nube privada; es decir, es el cliente quien tiene que hacer toda la gestión del producto y la infraestructura necesaria para que funcione.

API Gateway centralizado en la nube

En este caso también se tiene un único cluster para todo el tráfico pero en este caso se encuentra desplegado en la nube pública con la versión SaaS del producto; es decir, toda la infraestructura es delegada y autogestionada.

Habitualmente se opta por un modelo de compromiso que consiste en utilizar ambos patrones de despliegue; es decir, dos clusters independientes. Para consumo interno, sobre todo si hay temas legales involucrados, se opta por la implantación on-premise y para el consumo externo la implantación en la nube, en concreto, se utilizan versiones SaaS del producto en caso de que se tengan.

API Gateway distribuido

En este tipo de patrón se asigna un API gateway a un conjunto de servicios garantizando la asignación de recursos, la seguridad adecuada y el escalado independiente. La desventaja fundamental es la cantidad de API Gateways necesarios para aprovisionar la infraestructura y dependiendo del producto seleccionado no es una tarea sencilla.

API Gateway distribuido dedicado

En este patrón cada microservicio tiene un API gateway dedicado. Tiene como ventajas: disponer de recursos garantizados y una gestión más sencilla al no tener un único punto de entrada donde se maneja todo el tráfico. Tiene como desventajas que aumenta en uno el salto de red en la comunicación entre microservicios, lo mismo que ocurre con un API Gateway centralizado, además de la cantidad de gateways a gestionar.

API Gateway distribuido modo sidecar

En este patrón de despliegue se implanta de manera adjunta un API gateway al microservicio, como un sidecar a una motocicleta. La ventaja de este patrón es que reduce los saltos de red adicionales que se requerían en los patrones del API Gateway centralizado y modo distribuido dedicado para aquellos casos en los que se tenga una llamada interna entre microservicios al estar el API Gateway y el microservicio en el mismo pod.

Este patrón es el que se utiliza en service mesh que permite abstraer a los desarrolladores de las tareas de comunicación entre servicios como: el descubrimiento, enrutamiento, entrega confiable, etc, y que se focalicen en la implementación de la lógica de negocio que incluye el microservicio.

Tanto para el caso dedicado como en modo sidecar suele ser habitual el uso de API microgateways.

Un API Microgateway es una versión liviana y simplificada de un API gateway, es decir, solo admite un subconjunto de las capacidades que tiene un API Gateway. Se encuentra más cerca a nivel de red de los backend, siguiendo los patrones explicados anteriormente y generalmente realiza sus funciones de manera estanca (sin comunicarse con otros servidores para realizar algunas tareas, por ejemplo la verificación de la API key y del JWT), aunque eso depende del producto en sí.

API Gateway híbrido

Este patrón es una mezcla de todos los patrones anteriores, es decir, se utiliza en función del caso de uso lo mejor de cada uno de ellos.

• API Gateways centralizados on-premise para aquellas funcionalidades cuya latencia y requerimientos legales sean críticos. Por ejemplo para servicios legacy que ya están disponibles dentro de la organización y que se quieran exponer para consumo interno o controlado en entidades financieras.
• API Gateways centralizados en la nube en versión SaaS para casos de consumo externo, por ejemplo para APIs públicas, para partners o para aquellas APIs cuya funcionalidad se encuentra ya disponible en la nube pública.
• API Microgateways para aquel conjunto de funcionalidades que requieren un escalado específico o cuyo acceso sea crítico para así garantizar que no se compita por los recursos necesarios. Además tienen la ventaja de poder ejecutarse tanto on-premise como en la nube y cerca del backend, luego para casos cuya latencia sea un problema también se puede considerar como solución.

En caso de utilizar un producto de API Management se tendría:

• Un único plano de gestión con el API manager, API portal y analíticas centralizado, a ser posible en la nube y versión SaaS.
• Un plano de ejecución con el API gateway en aquel lugar donde mejor se adapte a la casuística en concreto, tal y como se ha explicado anteriormente.

Conclusiones

Actualmente los proveedores de productos API Management están mejorando la flexibilidad de despliegue del API Gateway para dar respuesta a los clientes que la reclaman por motivos de latencia, seguridad, legal, etc.

Para conseguirlo están siguiendo dos líneas de trabajo:

1. Ofrecer el API gateway de manera independiente al producto ofertando la posibilidad de implantarlo, tanto en la nube como on-premise, y permitiendo su conexión a un único plano de gestión.
2. Disponibilizar API Microgateways, quizá como solución táctica, hasta conseguir el punto 1 en todos los proveedores cloud y también para evitar tener piezas más complejas y centralizadas de las cuales los clientes intentan huir por complejidad de gestión y/o coste.

Referencias

Hybrid API Management

Behind the Buzzword: Microgateway

The Vision of Hybrid API Management

What is going on with the API Management market?

API Manager Microgateway

API Microgateway