Un servicio interno necesita obtener datos de usuario de un servicio de facturación, y cada milisegundo cuenta. Enrutar este tráfico interno a través de un gateway de borde orientado al público obliga a que la solicitud salga de la red privada, pase por firewalls externos y sufra una sobrecarga de serialización innecesaria. Esta ruta puede añadir fácilmente 30 milisegundos de latencia a una sola llamada de dependencia.
La comunicación interna de servicio a servicio requiere un enfoque arquitectónico diferente al enrutamiento de borde. En el borde, se necesitan portales públicos para desarrolladores, límites de tasa complejos para clientes externos y una validación OAuth2 pesada. Internamente, se necesita baja latencia, descubrimiento de servicios nativo y una fricción operativa mínima.
Elegir el API gateway adecuado para microservicios internos depende de cuánta carga operativa pueda manejar tu equipo frente a tu necesidad de rendimiento puro.
El desafío del enrutamiento de microservicios internos: Autohospedado vs. gestionado
Los arquitectos de plataformas se enfrentan a una elección fundamental al diseñar el enrutamiento interno: implementar y gestionar un gateway autohospedado cerca de los servicios, o delegar la infraestructura a un servicio en la nube gestionado.
Los gateways autohospedados se ejecutan dentro de tu red privada, a menudo como sidecars o controladores de ingreso en un clúster de Kubernetes. Este modelo de implementación mantiene el tráfico local, lo que minimiza la latencia. También te otorga un control total sobre las reglas de enrutamiento, la manipulación de cabeceras y las integraciones de descubrimiento de servicios con herramientas como Consul o Etcd. Sin embargo, tu equipo debe gestionar las máquinas virtuales subyacentes, las políticas de escalado y las actualizaciones.
Los gateways en la nube gestionados se ejecutan como servicios externos. Requieren casi cero mantenimiento y se escalan automáticamente para manejar picos de tráfico. La desventaja es la latencia y el costo. Cada solicitud interna debe viajar al endpoint del gateway del proveedor de la nube y volver a tu nube privada virtual (VPC). Este salto de red adicional introduce una latencia que puede degradar el rendimiento de las llamadas a microservicios encadenados.
Kong: Alto rendimiento con un ecosistema rico en plugins
Kong es un gateway de código abierto construido sobre el servidor web Nginx y la plataforma web OpenResty. Al heredar la arquitectura orientada a eventos de Nginx, Kong destaca en el enrutamiento de alto rendimiento y baja latencia.
[Solicitud interna] ---> [Kong Gateway (Nginx/OpenResty)] ---> [Microservicio destino]
|
[Plugins de Lua] (Autenticación, Límite de tasa, Logs)
Kong utiliza Lua para la extensibilidad. Si necesitas modificar cabeceras, inyectar tokens de autenticación o registrar solicitudes en Prometheus, aplicas un plugin. La versión de código abierto, Kong Gateway OSS, incluye una amplia selección de plugins de la comunidad. Para funciones empresariales avanzadas como el control de acceso basado en roles (RBAC) y la implementación multizona, los equipos deben realizar la transición a Kong Enterprise.
Gestionar Kong requiere administrar el estado de su configuración. Puedes ejecutar Kong en un modo de base de datos tradicional, que requiere una base de datos PostgreSQL para almacenar las configuraciones de enrutamiento. Alternativamente, puedes ejecutar Kong en modo sin base de datos (DB-less). En el modo DB-less, escribes las configuraciones en un archivo YAML declarativo y las aplicas directamente a la memoria del gateway. Este enfoque funciona bien en flujos de trabajo de GitOps y entornos de Kubernetes, pero significa que no puedes usar algunos plugins que requieren almacenamiento dinámico en base de datos.
Tyk: Completo en funciones y nativo en Go desde el primer momento
Tyk es un API gateway de código abierto escrito completamente en Go. A diferencia de Kong, que depende de una arquitectura de plugins modular para las funciones principales, Tyk incluye limitación de tasa, analíticas y virtualización de servicios directamente en su motor central.
Dado que Tyk está escrito en Go, resulta atractivo para equipos con experiencia previa en este lenguaje. Los desarrolladores pueden escribir plugins personalizados en Go, Python, JavaScript o Lua utilizando el coprocesador de plugins basado en gRPC de Tyk.
Tyk requiere Redis para funcionar. Utiliza Redis para el almacenamiento de sesiones, contadores de límite de tasa y almacenamiento en caché. Aunque esta dependencia de base de datos añade un componente operativo que gestionar, Redis permite a Tyk procesar altos volúmenes de tráfico con una latencia predecible y baja. La versión de código abierto de Tyk es altamente funcional y ofrece el mismo motor de gateway que la edición empresarial de pago, aunque el nivel empresarial añade un plano de control de gestión y un panel de control.
Opciones nativas de la nube: AWS API Gateway y servicios gestionados de plataforma
Si tu infraestructura se ejecuta por completo en una nube pública, las opciones gestionadas como AWS API Gateway, Azure API Management o Google Cloud Apigee son muy accesibles.
AWS API Gateway se integra directamente con otros servicios de AWS. Puedes enrutar una llamada de API entrante directamente a una función AWS Lambda, una cola SQS o un Application Load Balancer (ALB) interno sin escribir código de integración personalizado. La seguridad se gestiona a través de las políticas de AWS Identity and Access Management (IAM), lo que simplifica el control de acceso.
Sin embargo, los gateways gestionados en la nube introducen desventajas de rendimiento:
- Arranques en frío (Cold starts): Si te integras con backends serverless, la solicitud inicial puede tardar varios segundos en resolverse.
- Saltos de red: El tráfico a menudo debe salir de tu subred privada para llegar al endpoint público del gateway antes de volver a enrutarse a tu red privada.
- Dependencia del proveedor (Vendor lock-in): Las configuraciones están vinculadas a las API propietarias y herramientas de implementación del proveedor de la nube.
Para microservicios internos de alto rendimiento, estos factores pueden hacer que las opciones nativas de la nube sean menos adecuadas que las alternativas autohospedadas.
Marco de decisión: Elegir por tamaño de equipo y presupuesto operativo
Para elegir el gateway adecuado, evalúa la capacidad de tu equipo para gestionar la infraestructura frente a tus requisitos de rendimiento.
Equipos de startups pequeñas (1 a 10 desarrolladores)
Si tienes un equipo pequeño, prioriza una baja carga operativa. Utiliza el gateway gestionado de tu proveedor de nube (como AWS API Gateway) para poner en marcha tus servicios rápidamente. A esta escala, la facilidad de configuración y el modelo de cero mantenimiento compensan las pequeñas penalizaciones de latencia.
Equipos de plataforma medianos (10 a 50 desarrolladores)
A medida que tu malla de servicios crece, los costos de los gateways en la nube se escalan linealmente con el volumen de solicitudes. En esta etapa, el autohospedaje se vuelve viable financiera y operativamente.
Veamos una comparación de costos realista:
- Escenario gestionado (Ejemplo): Una aplicación mediana procesa 100,000,000 de solicitudes internas al día. Con un precio ilustrativo de gateway en la nube de $3.50 por millón de solicitudes, el costo de enrutamiento por sí solo es de $350 al día, o aproximadamente $10,500 al mes.
- Escenario autohospedado (Ejemplo): El mismo equipo implementa Kong o Tyk en su clúster de Kubernetes existente. Ejecutan tres instancias de cómputo pequeñas para alta disponibilidad, con un costo total de $150 al mes en recursos de cómputo.
La opción autohospedada ahorra un presupuesto significativo, pero requiere que el equipo de plataforma dedique unas pocas horas al mes a gestionar actualizaciones, monitorear Redis o PostgreSQL y configurar pipelines de implementación.
Equipos de plataforma empresariales (más de 50 desarrolladores)
Para organizaciones grandes con requisitos estrictos de cumplimiento y latencia inferior al milisegundo, los gateways autohospedados son casi siempre necesarios. Estos equipos suelen implementar Kong o Tyk en una configuración híbrida o de múltiples regiones para mantener el tráfico por completo dentro de los centros de datos locales o VPC.
| Criterio de selección | Kong | Tyk | AWS API Gateway |
|---|---|---|---|
| Lenguaje principal | Lua / C | Go | Propietario |
| Dependencia de base de datos | PostgreSQL o DB-less | Redis | Ninguna (Gestionado) |
| Extensibilidad | Plugins de Lua | Go, Python, gRPC | Integraciones de AWS |
| Perfil de latencia | Menor a un milisegundo | Bajo (rango de microsegundos) | Moderado (saltos de red) |
| Mejor ajuste | Entornos Nginx de alto rendimiento | Equipos centrados en Go que buscan funciones listas para usar | Arquitecturas serverless y puras de AWS |
Evalúa tus opciones de infraestructura de API en StackMatch
Seleccionar el API gateway adecuado es una decisión arquitectónica crítica que afecta la latencia, el costo y la complejidad operativa de tu sistema. Puedes explorar más opciones y comparar estas herramientas en profundidad en StackMatch. StackMatch ofrece listados de herramientas seleccionadas, páginas de comparación directa y puntuaciones editoriales basadas en la facilidad de uso, la transparencia de precios y las integraciones para ayudar a los ingenieros de plataformas a encontrar la opción adecuada para su pila tecnológica específica.
Preguntas frecuentes
¿Es Kong más rápido que AWS API Gateway para el enrutamiento interno?
Sí, Kong generalmente ofrece una latencia significativamente menor que AWS API Gateway. Debido a que Kong se ejecuta en Nginx y se puede implementar dentro de tu VPC privada cerca de tus microservicios, evita los saltos de red y los arranques en frío asociados con el servicio totalmente gestionado de AWS.
¿Puedo ejecutar Tyk sin una base de datos?
Tyk requiere Redis para el almacenamiento en caché, la limitación de tasa y el almacenamiento de sesiones. Aunque no puedes ejecutarlo de manera completamente sin estado sin Redis, esta arquitectura permite a Tyk manejar tráfico de alto rendimiento con una latencia mínima en comparación con los gateways que dependen de bases de datos relacionales.
¿Cuándo debería un equipo hacer la transición de un gateway nativo de la nube a uno autohospedado?
Los equipos suelen hacer la transición cuando las facturas del gateway nativo de la nube escalan linealmente con el volumen de llamadas a la API, o cuando la latencia añadida del enrutamiento WAN afecta el rendimiento de los microservicios internos. Si tus servicios internos requieren tiempos de respuesta inferiores a 10 ms, normalmente es necesario autohospedar Kong o Tyk en Kubernetes.
¿Cómo manejan Kong y Tyk gRPC y GraphQL?
Ambos gateways admiten el enrutamiento gRPC y GraphQL, pero lo manejan de manera diferente. Kong utiliza plugins para la transcodificación de gRPC y la validación de esquemas GraphQL, mientras que Tyk ofrece capacidades nativas de motor GraphQL para fusionar múltiples esquemas en un solo grafo directamente desde el primer momento.