Patrones de Implementación de API Gateway
December 16, 2022
APIs están cambiando la forma en que construimos aplicaciones y la forma en que exponemos datos, tanto dentro como fuera de nuestras organizaciones. Además, el éxito de nuestras APIs depende de su integridad, disponibilidad y rendimiento. Con una API Gateway como Apache APISIX, podemos lograr estos indicadores de éxito.
Cuando se trata de la implementación de API Gateways, existen 4 patrones bien conocidos: Gateway centralizado en el borde, Gateway de dos niveles, Microgateway y Sidecar. En esta publicación, revisaremos estos patrones y te daremos una idea para elegir el patrón de implementación de API Gateway adecuado para tu negocio.
¿Qué es un API Gateway?
Un API Gateway es una herramienta de gestión que se sitúa en el borde de un sistema entre un consumidor y una colección de servicios backend, actuando como un punto de entrada único para un grupo definido de APIs. El consumidor puede ser una aplicación o dispositivo de usuario final, como una aplicación web de una sola página o una aplicación móvil, otro sistema interno, o una aplicación o sistema de terceros.
Componentes de implementación de un API Gateway
Un API Gateway se implementa con dos componentes fundamentales de alto nivel: un plano de control y un plano de datos. Estos componentes generalmente pueden empaquetarse juntos o implementarse por separado. El plano de control es donde los operadores interactúan con el gateway y definen rutas, políticas y la telemetría requerida. El plano de datos es el lugar donde ocurre todo el trabajo especificado en el plano de control, se enrutan los paquetes de red, se aplican las políticas y se emite la telemetría. Por ejemplo, APISIX tiene tres modos de implementación diferentes (tradicional, desacoplado y autónomo) para diferentes casos de uso en producción.
Gateway centralizado en el borde
Un API Gateway generalmente se implementa en el borde de un sistema, pero la definición de "sistema" en este caso puede ser bastante flexible. Para startups y muchas pequeñas y medianas empresas, un API Gateway a menudo se implementará en el borde del centro de datos o de la nube. En estas situaciones, puede haber solo un único API Gateway (implementado y ejecutándose a través de múltiples instancias para alta disponibilidad) que actúa como la puerta de entrada para toda la infraestructura backend, y el API Gateway proporcionará toda la funcionalidad de borde.
Un API Gateway proporciona requisitos transversales como autenticación de usuarios, autorización, limitación de tasa de solicitudes, almacenamiento en caché, tiempos de espera/reintentos, transformación de solicitudes/respuestas, puede proporcionar métricas, registros y datos de trazado para apoyar la implementación de la observabilidad dentro del sistema.
Además, muchos API Gateways ofrecen características adicionales que permiten a los desarrolladores gestionar el ciclo de vida de una API, ayudar con la incorporación y gestión de desarrolladores que utilizan las APIs (como proporcionar un portal para desarrolladores y la administración de cuentas y control de acceso relacionado), y proporcionar gobernanza empresarial.
Gateway de dos niveles
Para grandes organizaciones y empresas, un API Gateway generalmente se implementará en múltiples ubicaciones, a menudo como parte de la pila de borde inicial en el perímetro de un centro de datos, y se pueden implementar gateways adicionales como parte de cada producto, línea de negocio o departamento organizacional. En este contexto, estos gateways serían más típicamente implementaciones separadas y pueden ofrecer diferentes funcionalidades dependiendo de la ubicación geográfica (gobernanza requerida) o las capacidades de infraestructura (ejecutándose en recursos de computación de borde de baja potencia).
Como muestra el siguiente diagrama, Apache APISIX API Gateway a menudo se sitúa entre la internet pública y la zona desmilitarizada (DMZ) de una red privada.
Microgateway
Microgateways están diseñados completamente para la comunicación interna entre microservicios. Cada microgateway individual puede tener un conjunto diferente de políticas, reglas de seguridad y requerir la agregación de monitoreo y métricas de múltiples servicios.
El concepto es proporcionar la capacidad (un gateway dedicado) al equipo individual que gestiona los microservicios para controlar cómo van a exponer de manera segura los servicios. El mismo equipo de desarrolladores gestionará y mantendrá sus microservicios y microgateways, por lo que pueden corregir errores, proporcionar actualizaciones, realizar mejoras de manera independiente y enviar rápidamente los cambios a producción con menos interacción con otras dependencias y sin afectar otras aplicaciones en la implementación.
Sidecar API Gateway
Sidecar implementa un API Gateway como un contenedor adjunto a un servicio en un entorno de ejecución independiente, como Kubernetes. Sidecar es un patrón que corresponde a un sidecar adjunto a una motocicleta, de manera similar, está adjunto a una aplicación principal (un componente de software llamado service mesh) y proporciona características de soporte para la aplicación. El sidecar también comparte el mismo ciclo de vida que la aplicación principal, se crea y se retira junto con la principal, e introduce características adicionales como monitoreo, registro, configuración y servicios de red.
Los beneficios de adoptar este patrón son que cada entorno de ejecución de servicio puede configurar su propio API Gateway de la mejor manera. Debido a que el requisito para habilitar las funcionalidades y configuraciones del API Gateway puede variar de un servicio a otro. Al mismo tiempo, separa las preocupaciones si ocurre un problema en la infraestructura compartida del API Gateway, entonces no todos los servicios se ven afectados. Por ejemplo, Amesh es otra solución de service mesh basada en Apache APISIX.
El diagrama anterior ilustra un ingress actuando como un balanceador de carga de API y enrutador de recursos hacia cada punto final de servicio. El punto de entrada para el servicio no es el punto final del servicio en sí, sino un sidecar API Gateway. El sidecar puede entonces realizar cualquiera de las capacidades ofrecidas por el API Gateway además de enrutar el tráfico al punto final del servicio.
Conclusión
Como entendemos, no existe un único patrón de implementación que sea adecuado para todas las condiciones. A veces puedes usar uno o múltiples gateways en tu sistema. La elección de la implementación depende de la complejidad y las necesidades de tu negocio. Si necesitas ayuda para decidir qué patrón de implementación sería el mejor para ti, puedes unirte a nuestro canal de Slack y los expertos te ayudarán a tomar una decisión.
Recursos relacionados
➔ Modelos de implementación de Apache APISIX.
➔ ¿Qué es un API Gateway y por qué es esencial en la era de la nube nativa?.
Contenido recomendado
➔ Lee las publicaciones del blog: