Un API gateway central gestiona la autenticación, el enrutamiento y la limitación de velocidad entre servicios. A escala, se convierte en un cuello de botella de coordinación. Aquí explicamos cómo sustituirlo por AWS API Gateways por equipo, respaldados por un autorizador impulsado por Kafka y un portal de desarrolladores central, recupera la autonomía de los equipos sin sacrificar la gobernanza.
Conclusiones clave
- Un API gateway central se convierte en un cuello de botella para el negocio a escala: ralentiza la entrega, aumenta el riesgo de incidentes compartidos y convierte al equipo de plataforma en una función de control para todos.
- Las instancias de gateway por equipo permiten que los equipos de producto desplieguen nuevas APIs sin depender de una ventana de release compartida, lo que reduce el onboarding a una tarea de un solo equipo.
- Centralizar la política de autenticación en un portal de desarrolladores preserva la gobernanza sin acoplar los cambios de cumplimiento a los despliegues de infraestructura.
- Las actualizaciones de política se propagan a cada gateway en cuestión de segundos mediante eventos Kafka, de modo que los cambios de seguridad y cumplimiento se aplican sin releases coordinados.
- Colocar el gateway de cada equipo en su propia cuenta de AWS hace que los costes del tráfico de API sean visibles donde se toman las decisiones de producto que los generan.
- El equipo de plataforma deja de ser un cuello de botella para cada lanzamiento de API y pasa a ser responsable del módulo, el autorizador y el contrato de eventos.
Tu API gateway se sitúa en el perímetro de tu entorno de aplicaciones. Es donde se recibe el tráfico de apps móviles, plataformas de partners, herramientas internas y otros servicios antes de que llegue a los sistemas backend que lo procesan. Durante mucho tiempo tiene sentido ejecutar uno de forma centralizada: el enrutamiento, la limitación de velocidad, la autenticación y la observabilidad pasan por un único lugar, operado por un único equipo, bajo un único contrato que todos los equipos de servicio deben respetar.
Luego la organización crece, y ese mismo gateway empieza a costarte de maneras que no aparecen en el diagrama de arquitectura. La gráfica de tráfico sube, y también la factura de la licencia, porque el modelo comercial tiene un precio por petición. El calendario de releases se llena, pero cada cambio toca la misma configuración, así que los cambios se van acumulando en cola. Una ruta mal configurada puede dejar fuera de servicio endpoints que pertenecen a equipos que nunca se han conocido. El equipo de plataforma que gestiona el gateway se convierte en el cuello de botella que nadie quiere ser, y el único equipo capaz de desbloquear a todos los demás.
A cierta escala, el gateway deja de ser un elemento de infraestructura y se convierte en un problema de coordinación.
Ese fue el punto en el que nosotros, trabajando con un gran cliente empresarial cuya organización de ingeniería había crecido hasta abarcar decenas de equipos distribuidos en múltiples cuentas de AWS, decidimos desmontarlo.
Figura 1: La misma lógica de autorizador y fuente de política, dos topologías de despliegue muy distintas.
El problema no era el gateway: era dónde vivía
La centralización funciona bien cuando hay cinco servicios detrás. Resulta costosa, tanto económica como organizativamente, cuando hay decenas, pertenecientes a equipos que despliegan en cadencias distintas, en cuentas de AWS diferentes, con perfiles de latencia y cumplimiento muy distintos.
Tres presiones nos empujaron hacia un modelo descentralizado:
- Visibilidad de costes. Con un único gateway compartido, el tráfico de cada equipo desaparecía en una única partida de gasto. No había forma de que un equipo de producto viera que su nueva funcionalidad había duplicado el rendimiento de la API y, por tanto, no podía sopesar ese tráfico frente al valor de negocio que generaba. Las decisiones que deberían haberse tomado localmente se tomaban lejos de las personas cualificadas para hacerlo.
- Radio de explosión. Una errata en una ruta, un límite de velocidad demasiado agresivo o una mala configuración del autorizador podían afectar a APIs de toda la empresa. La infraestructura compartida implica un destino compartido, y el destino compartido acaba implicando incidentes compartidos.
- Rendimiento de cambios. Cada nuevo servicio, cada actualización de regla de autenticación y cada reescritura de cabecera pasaban por un único equipo. Ese equipo era bueno. Seguía siendo solo un equipo.
Ninguno de estos problemas es inusual. Suelen aparecer juntos, y suelen hacerlo más o menos cuando un equipo empieza a realizar revisiones de capacidad trimestrales del propio gateway. Si tu gateway central aparece en demasiadas reuniones de revisión de arquitectura, probablemente ya estés pagando estos costes sin haberlos identificado.
Lo que cambiamos
Sustituimos el gateway central por un bloque de construcción pequeño y replicable: un AWS API Gateway más un autorizador Lambda, empaquetados como un módulo Terraform desplegable. Cada equipo de servicio despliega una instancia en su propia cuenta de AWS, delante de sus propios servicios. Ellos son los dueños de las rutas, los despliegues y la factura.
Esa descripción es fácil de escribir y más difícil de vivir. La parte difícil no es desplegar gateways; es asegurarse de que la consistencia no se desmorona en el momento en que sueltas el único gateway compartido. Tres decisiones de diseño hicieron la mayor parte de ese trabajo.
El autorizador es el contrato
El enrutamiento y la limitación de velocidad pueden variar por equipo; la autenticación no. Cada gateway ejecuta la misma lógica de autorizador, distribuida como parte del mismo módulo Terraform. Si un equipo consume el módulo, obtiene el comportamiento de autenticación de toda la organización de forma gratuita. No puede divergir de él accidentalmente. Ese es el mecanismo que permite al equipo de plataforma relajar el control sobre dónde se ejecutan los gateways sin perder el control sobre cómo autorizan.
La configuración fluye a través del portal de desarrolladores como eventos
La configuración del autorizador se publica desde el portal de desarrolladores central como mensajes Kafka. Esto cubre qué clientes son válidos, qué scopes se asignan a qué APIs y qué claves han sido rotadas. Cada autorizador se suscribe al topic y actualiza su vista en memoria. Un cambio de scope realizado en el portal a las 10:01 está en vigor en cada gateway en cuestión de segundos, sin necesidad de un despliegue.
La gestión no tiene que ser infraestructura centralizada; puede ser un flujo de datos centralizado sobre infraestructura descentralizada
Joachim Spalink, ingeniero de software sénior, Mimacom
El portal sigue siendo la única fuente de verdad sobre cuál es la política; los gateways son simplemente los lugares que la aplican. La gestión no tiene que ser infraestructura centralizada; puede ser un flujo de datos centralizado sobre infraestructura descentralizada. Esa distinción es el núcleo del enfoque.
La configuración también puede estar integrada en el código
La disponibilidad de Kafka no es la apuesta correcta para tu ruta de autenticación. El mismo módulo autorizador acepta una configuración integrada en el despliegue. Esto importa en tres situaciones: arranques en frío, donde el autorizador no debería esperar a una puesta al día del topic antes de atender su primera petición; cortes de Kafka, donde el autorizador sigue funcionando con su última configuración válida conocida en lugar de fallar de forma cerrada por razones ajenas a la autenticación; y entornos perimetrales o restringidos donde la conexión con el portal de desarrolladores no está disponible.
El portal es la fuente de verdad en estado estable. La configuración integrada es el suelo.
Dos variantes de autorizador, elegidas según la carga de trabajo
Existen dos versiones del autorizador. La variante en Rust sirve rutas sensibles a la latencia donde cada milisegundo de sobrecarga de autorización es visible en las métricas de producto o en la sensibilidad al arranque en frío. La variante en TypeScript es para equipos cuyas APIs no están en la ruta crítica y cuyos ingenieros ya dominan Node. Ambas consumen la misma configuración y aplican las mismas reglas. La elección es un compromiso entre ergonomía y rendimiento que el equipo toma localmente, no una decisión que el equipo de plataforma tiene que tomar en su nombre.
Cómo se manifiesta en la práctica
El cambio es más visible en tres momentos de la vida de un equipo.
Incorporación de un nuevo servicio. Anteriormente, incorporar una nueva API implicaba abrir un ticket al equipo de plataforma, un ciclo de revisión, un cambio de configuración en el gateway compartido y un despliegue coordinado con la ventana de release de todos los demás. Ahora es terraform apply contra un módulo que el equipo ya conoce, con un comportamiento de autenticación sobre el que no tienen que razonar porque viene incluido en el módulo. La incorporación se convierte en una tarea de un solo equipo en lugar de un problema de coordinación entre varios equipos.
Implantación de un cambio de autenticación. Revocar un scope en todo el sistema antes requería un rollout coordinado: un cambio en el gateway central, una ventana, un despliegue y una verificación. Ahora es un cambio en el portal de desarrolladores que se propaga como un evento Kafka. En decenas de gateways, la nueva política está activa en cuestión de segundos. El trabajo del equipo de plataforma ha subido de nivel. Ya no operan el gateway; son responsables del módulo, el código del autorizador y el contrato de eventos.
Leer la factura. Como el gateway de cada equipo vive en su cuenta, su tráfico es su coste. Un equipo que lanza un cliente con mucho tráfico y triplica su volumen de peticiones ve el coste en su propia factura de AWS ese mismo mes. Esa señal llega a las personas que pueden actuar sobre ella, el equipo que posee la API, en lugar de absorberse en una partida de plataforma que nadie lee. Mientras tanto, la licencia con precio por tráfico del antiguo gateway central simplemente desapareció; ese coste no se redistribuyó: se eliminó.
Figura 2: Un único cambio en el portal de desarrolladores llega a cada gateway de la flota mediante un evento Kafka, con un fallback integrado para arranques en frío e interrupciones.
Compensaciones que vale la pena reconocer
La descentralización no es gratuita. Algunas de las compensaciones que vale la pena mencionar si estás evaluando este patrón.
Asumes una flota. Ya no gestionas un gateway; gestionas decenas. El módulo los hace homogéneos, pero la observabilidad, el rollout de versiones y las pruebas de extremo a extremo deben diseñarse para la flota, no para la instancia única.
El topic Kafka entre el portal de desarrolladores y los autorizadores se convierte en una dependencia crítica. Su esquema, retención y semántica de replay importan. La configuración integrada mitiga las interrupciones, pero no sustituye la necesidad de operar ese contrato con cuidado.
La coordinación cambia, pero no desaparece. Los equipos de servicio coordinan menos con el equipo de plataforma, pero más entre sí en asuntos transversales como la política CORS, los formatos de error y las convenciones de observabilidad. El módulo es donde viven estas convenciones. Mantenerlo opinionado es más valioso que mantenerlo flexible.
Ninguna de estas razones es motivo para no hacerlo. Son razones para ser deliberados en cómo se hace.
Lo que esto significa para los equipos
Para los ingenieros, el cambio cotidiano tiene que ver con la propiedad y la fricción. El gateway ya no es una pieza de infraestructura remota contra la que abren tickets; es un módulo en su repositorio. Pueden leerlo, depurarlo localmente y razonar sobre sus modos de fallo. El autorizador solo es una caja negra en el sentido de que los equipos no tienen que pensar en él; aun así pueden leerlo y depurarlo cuando sea necesario.
Para quienes toman decisiones, el cambio más importante es estructural. Los costes de API se vuelven legibles a nivel de equipo, lo que permite que la dirección de ingeniería y producto mantenga conversaciones honestas sobre tráfico, crecimiento y economía unitaria. La gobernanza y la infraestructura también dejan de estar acopladas: el portal de desarrolladores puede mantenerse estricto (un lugar, una política) mientras que la infraestructura de aplicación puede extenderse tanto como la organización necesite. El equipo de plataforma escala de forma sublineal con respecto al resto de la ingeniería. Ya no es la función de control para cada nuevo servicio; en cambio, mantiene el módulo, el autorizador y el contrato de eventos.
Ese último punto es donde vive realmente el escalado de esta historia. El hardware y el rendimiento escalan fácilmente. Lo que no escala, en una organización de ingeniería en crecimiento, es la sobrecarga de coordinación humana de cualquier pieza de infraestructura que todos los equipos tienen que compartir. Descentralizar el gateway es una de las formas más limpias de sacar esa sobrecarga de la ruta crítica.
¿Quieres hablar sobre un cambio similar?
Si tu API gateway central aparece en revisiones de capacidad, renovaciones de licencias o retrospectivas de incidentes con más frecuencia de la que parece saludable, vale la pena considerar tres movimientos.
El movimiento más importante es desacoplar la política de la aplicación. Mantén el portal de desarrolladores como fuente de verdad y deja que los puntos de aplicación se multipliquen. Los eventos son un mejor mecanismo de distribución de políticas que los tickets. Empaqueta el gateway como un módulo en lugar de un servicio que opera el equipo de plataforma: su producto se convierte en el IaC, el autorizador y la ruta de actualización, no en la infraestructura en ejecución.
Hacer que el coste sea una señal local es el tercer movimiento. Poner los gateways en cuentas propiedad de los equipos convierte el tráfico de API en un número que el equipo que lo genera puede ver realmente, en lugar de una partida de plataforma que nadie lee.
La forma de la respuesta es sencilla. El trabajo duro está en los contratos: la API del módulo, el esquema de configuración del autorizador y el flujo de eventos entre el portal de desarrolladores y la flota. Acierta en esos, y el resto se alinea. Tanto si estás valorando un paso hacia la descentralización, diseñando un portal de desarrolladores o repensando cómo llega la política a tu runtime, nuestros equipos de DevOps y Platform Engineering y Cloud Engineering estarían encantados de compartir experiencias.
