Un solo punto de entrada para veinte microservicios

Veinte servicios expuestos a internet, cada uno por su cuenta, es más normal de lo que parece. Empiezas con dos APIs, cada una con su seguridad. Llegas a veinte y nadie sabe ya quién entra por dónde. Este es el caso de una empresa que tenía ese problema y lo resolvió con una decisión de arquitectura pequeña —una sola puerta de entrada— y un contrato de continuidad para que la puerta siguiera siendo una puerta.

Este caso es para quien tiene servicios expuestos «cada uno por su cuenta». Si lo que buscas es quién conecte tus sistemas entre sí, la página es integración de software; si buscas quién te construya y mantenga una plataforma, desarrollo de software a medida. Y si quieres que lo miremos contigo, cuéntanos el caso.

El punto de partida

El cliente es una empresa del sector agroalimentario con una infraestructura tecnológica que había crecido en dos direcciones a la vez. Por un lado, un clúster de Kubernetes en Google Cloud (GKE) con servicios propios —algunos de ellos construidos por Arteco en proyectos anteriores—. Por otro, los sistemas de siempre en sus instalaciones: bases de datos, aplicaciones de gestión y el directorio de usuarios de la empresa, un Microsoft Active Directory que lleva años siendo la fuente de verdad de quién es quién.

Entre las dos mitades había una VPN, y por encima de las dos, internet: servicios que había que exponer al exterior y otros que había que exponer dentro de la organización. Cada API se había publicado cuando hizo falta y por su cuenta, sin una autenticación común ni una vista unificada de quién la usaba y cómo respondía. Cuando una empresa llega a ese punto, el cuadro es casi siempre el mismo, y aquí no era distinto en lo esencial:

• Cada servicio resuelve la seguridad a su manera, y la manera depende de quién lo hizo y cuándo.
• Cada uno registra lo que le parece, en el formato que le parece, en su propio sitio.
• Si alguien hace demasiadas peticiones, se nota cuando el servicio va lento, no antes.
• Y cuando hay que auditar quién ha accedido a qué, hay que mirar en tantos sitios como servicios.

Nada de esto está roto. Cada pieza hace su trabajo. Lo que pasa es que el perímetro deja de ser un perímetro: es una colección de puertas, cada una con su propio candado. Con cada servicio nuevo, el problema crece; y el equipo de sistemas, que es el que responde cuando algo entra por donde no debe, tiene cada vez menos visibilidad sobre el conjunto.

La necesidad de fondo no era «un API Gateway»: era poder seguir exponiendo servicios —hacia fuera y hacia dentro de la organización— sin que cada uno abriera un agujero nuevo en el perímetro. Eso es lo que de verdad había que resolver.

Por qué la respuesta no era otro servicio más

La tentación, cuando hay que exponer algo nuevo, es hacer lo que se hizo las otras diecinueve veces: abrirlo, ponerle su seguridad y seguir. Es lo más rápido y es lo que hace que el problema crezca.

La otra tentación es la contraria: parar, diseñar el perímetro perfecto y rehacer los veinte servicios para que encajen. Eso no lo hace nadie, porque los veinte servicios están en producción y la empresa no se puede permitir pararlos.

Lo que propusimos está entre las dos: poner una pieza nueva delante de todo lo que ya existía, sin tocar lo que ya existía. Un API Gateway. Una sola puerta por la que pasa cualquier petición que venga de internet, y que decide tres cosas antes de dejarla seguir: si entra, con qué identidad entra y hacia dónde va. Los servicios de detrás no se enteran de nada: siguen funcionando igual, solo que ahora nadie llega a ellos sin pasar por la puerta.

Esa decisión tiene una consecuencia que vale más que cualquier característica técnica: la seguridad se configura una vez. Límite de peticiones, protección frente a los ataques comunes, cabeceras, cifrado, autenticación: todo eso deja de ser responsabilidad de cada servicio y pasa a ser responsabilidad de la puerta. El servicio número veintiuno, el día que se exponga, tendrá la misma seguridad que los otros veinte sin que nadie tenga que acordarse de ponérsela.

Qué hace la puerta, petición a petición

Conviene bajarlo a lo concreto, porque «API Gateway» suena a caja negra y no lo es. Cada vez que algo llega desde internet, el gateway hace, en este orden:

1. Comprueba la ruta. ¿Existe lo que piden? ¿Está publicado? Si no, fuera, sin molestar a ningún servicio.
2. Aplica los límites. Cada consumidor tiene una cuota de peticiones por segundo y por minuto. Un proveedor con un bucle mal hecho ya no tumba un servicio: se le frena en la puerta, se le contesta con un error claro y se registra.
3. Verifica la identidad. Aquí está la parte que más cambió la vida al equipo de sistemas. El gateway valida quién llama contra el Active Directory de la empresa, por OIDC/LDAP. Las mismas cuentas, los mismos grupos y las mismas bajas que ya gestiona sistemas sirven para decidir quién accede a qué API. Cuando una persona deja la empresa y se le da de baja en el directorio, deja de entrar también por las APIs, sin que nadie tenga que acordarse de revocar nada en veinte sitios.
4. Enruta. Según la ruta y la identidad, la petición va a un servicio del clúster o, a través de la VPN, a un sistema de las oficinas. El que llama no sabe dónde está lo que llama, y eso es a propósito: mañana un sistema puede moverse de las oficinas a la nube y nadie fuera se enterará.
5. Registra. Métricas, trazas y logs de cada petición, en un solo sitio y con el mismo formato. Quién, cuándo, qué, cuánto tardó, qué devolvió.

Todo esto lo hace en milisegundos. La pieza elegida, Apache APISIX, está construida sobre Nginx y OpenResty y se mueve en esas latencias incluso con mucho tráfico; para el usuario final la puerta es invisible.

Las decisiones que importaban (y por qué)

Un proyecto así tiene pocas decisiones, pero hay que tomarlas bien. Estas fueron las que discutimos con el cliente.

Apache APISIX y no otra cosa. Había alternativas: gateways gestionados del proveedor de nube, otras piezas de código abierto, soluciones comerciales. APISIX ganó por cuatro motivos concretos. Rinde mucho: está construido sobre Nginx y OpenResty y se mueve en milisegundos incluso con mucho tráfico. Se configura en caliente: rutas, políticas y plugins se cambian sin reiniciar, lo que en un perímetro en producción no es un lujo sino una necesidad. Trae más de ochenta plugins para autenticación, tráfico, seguridad y observabilidad, así que casi nada hay que programarlo. Y es código abierto bajo la Apache Software Foundation, sin licencias por petición ni por servicio: el coste no crece con el uso.

En el clúster que ya existía, no en otro sitio. El cliente ya operaba GKE. Poner el gateway allí significaba reutilizar el despliegue, el escalado y la monitorización que ya tenían, en vez de añadir una máquina más que alguien tendría que cuidar aparte.

Autenticación contra el directorio corporativo, no una nueva. Habría sido más rápido darle al gateway su propia base de usuarios. Habría sido también una fuente más de verdad que mantener, y en una empresa el número de sitios donde hay que dar de baja a una persona es exactamente el número de sitios donde se olvidará hacerlo. Integrar con Active Directory costó algo más al principio y quita trabajo todos los meses.

Observabilidad con Prometheus y Grafana, desde el primer día. No como extra: como parte del alcance. Un gateway sin métricas es una caja por la que pasan cosas que nadie ve. Con métricas es el sitio desde el que se entiende todo el tráfico de la empresa hacia fuera: qué API se usa, cuánto tarda, cuándo falla, quién la consume. Eso no se añade después; si no está al principio, no está.

Una puerta para los dos mundos. La decisión de que detrás del gateway convivieran servicios del clúster y sistemas de las oficinas —por VPN— fue la que convirtió el proyecto en una solución y no en un parche. Si el gateway solo hubiera cubierto la nube, la mitad de las puertas habría seguido abierta por su cuenta.

Cómo se hizo, en cuatro fases

Un perímetro en producción no se cambia un viernes por la tarde. El proyecto se planteó en cuatro fases, con un equipo de dos personas, y el orden está pensado para que cada paso sea pequeño y se pueda deshacer:

1. Análisis, diseño y estrategia de identidad. Requisitos de seguridad y rendimiento, elección definitiva del motor y —lo más delicado— una prueba de concepto de la integración con Active Directory antes de construir nada encima. Aquí se define también el formato estándar de los logs: si cada servicio registra a su manera, la observabilidad no existe.
2. Despliegue de la plataforma. Instalación del gateway en el clúster (plano de datos y plano de control), y la pieza que convierte la puerta en la única puerta: el Ingress del clúster redirige todo el tráfico externo exclusivamente al gateway. Se comprueba conectividad y latencia hacia los servicios del clúster y hacia los sistemas de las oficinas a través de la VPN.
3. Integraciones de seguridad y monitorización. Autenticación contra Active Directory (inicio de sesión único para personas y autenticación máquina a máquina para integraciones), el stack de observabilidad —peticiones, latencias, tasas de éxito, exportación de métricas— y las políticas de resiliencia y seguridad por plugins.
4. Rutas, pruebas y traspaso. Configuración de las rutas hacia las APIs del clúster (un pool mixto de tecnologías) y hacia la red de las oficinas, pruebas de extremo a extremo, y entrega del Libro Operativo del Gateway: la documentación con la que el equipo del cliente puede dar de alta sus propias rutas y políticas por configuración (YAML, CRDs) sin depender de nadie.

Esa cuarta fase es importante y se suele olvidar: el gateway no es una caja que solo Arteco sabe abrir. El equipo técnico del cliente se queda con el libro y con la capacidad de operar su propia puerta. Lo que Arteco sigue haciendo después es otra cosa (ver más abajo).

Qué se incluyó sin que estuviera en el título

• Una puesta a punto del clúster de Kubernetes, incluida en la fase de implementación: el gateway iba a ser la pieza más expuesta del clúster, y no tenía sentido montarla sobre una base sin revisar.
• El gateway no toca los servicios. Se encarga exclusivamente de las políticas transversales —seguridad, tráfico, autenticación, observabilidad— y libera a los servicios de detrás de esa responsabilidad. Ninguno se rehizo para «aprovechar»: es lo que mantiene el riesgo bajo y permite mejorar un servicio concreto cuando toque, no todos a la vez.

El resultado

El cliente dispone hoy de una sola puerta de entrada a sus APIs, con la misma seguridad, la misma autenticación y la misma visibilidad para todas. El alcance entregado cubre hasta veinte microservicios, entre el clúster y las oficinas, y el servicio número veintiuno entrará por la misma puerta sin que nadie tenga que acordarse de nada.

No vamos a poner aquí un porcentaje de mejora, porque no hay uno medido: lo que hay es un perímetro que antes no existía como tal y ahora sí, un equipo de sistemas que puede contestar a «¿quién ha accedido a qué?» mirando en un sitio en vez de en veinte, y un libro operativo con el que ese equipo gestiona su propia puerta. Si algún día el cliente quiere poner cifra a eso, será su cifra.

Lo que más nos gusta del proyecto no es la arquitectura

Es que no acabó en la entrega. El gateway se contrató junto con un mantenimiento mensual de cuota fija y compromiso anual: revisión periódica de la salud del gateway y de su observabilidad, parches y actualizaciones de seguridad de las imágenes y plugins, auditoría de las copias de la configuración, y una bolsa de ocho horas al mes para dar de alta rutas, ajustar políticas de acceso y resolver dudas del equipo técnico. Cubre hasta veinte aplicaciones o microservicios detrás de la puerta; si el ecosistema crece, se revisa el tramo, y cada año se evalúa juntos cómo ha ido.

Esto no es un detalle comercial. Un API Gateway es una pieza de seguridad, y una pieza de seguridad sin actualizar es una puerta que parece cerrada. Las versiones nuevas de APISIX corrigen vulnerabilidades; las reglas de acceso cambian cuando cambia la empresa; los servicios de detrás evolucionan y hay que comprobar que siguen respondiendo como deben. Alguien tiene que hacer eso cada mes, y ese alguien tiene que conocer la pieza. Por eso proponemos el mantenimiento junto con el proyecto y no después: el momento en que el cliente mejor entiende por qué lo necesita es el día de la entrega.

Es, además, la forma de trabajar que más nos gusta: entregar algo que funciona y seguir siendo los que lo cuidan. Una puerta solo sigue siendo una puerta si alguien la cuida.

¿Te suena? Señales de que te hace falta una puerta

No todas las empresas necesitan un API Gateway. Estas son las señales de que sí, sacadas de este proyecto y de otros parecidos:

• Tienes más de cuatro o cinco servicios expuestos a internet, y cada uno con su propia forma de autenticar.
• Cuando alguien deja la empresa, hay que revocarle el acceso en varios sitios y no siempre se hace en todos.
• Un proveedor o una integración externa ha tumbado o ralentizado un servicio por hacer demasiadas peticiones.
• Si te preguntan «¿quién ha llamado a esta API esta semana?», la respuesta empieza por «déjame mirar en…».
• Tienes sistemas en la nube y en tus oficinas y los expones por caminos distintos.
• Vas a exponer más cosas en los próximos meses y te da respeto.

Si te reconoces en tres de estas, la conversación merece la pena. Si te reconoces en una, quizá todavía no; y te lo diremos igual.

Preguntas frecuentes

¿Qué es exactamente un API Gateway y para qué sirve? Es una pieza que se pone delante de todos los servicios que expones a internet y por la que pasa cada petición. Decide si entra, con qué identidad, hacia qué servicio va y con qué límites, y registra lo que pasa. Sirve para que la seguridad, la autenticación y la observabilidad se configuren una vez, en vez de una por servicio.

¿Hace falta tener Kubernetes? No. Un gateway se puede desplegar en una máquina virtual o en un servidor propio. Kubernetes lo hace más cómodo de operar, escalar y actualizar, y en este caso el cliente ya tenía un clúster, así que era el sitio natural. Lo que cambia la decisión es cuántos servicios hay detrás y cuántos sistemas distintos tienen que quedar cubiertos.

¿Cuánto se tarda, con los servicios ya en producción? Depende del número de servicios y de si la autenticación ya existe en algún sitio. Aquí el proyecto se planteó en cuatro fases —análisis y prueba de concepto de la identidad, despliegue, integraciones, rutas y pruebas— precisamente para que cada paso fuera pequeño y reversible y el perímetro se cerrara al final, no al principio.

¿Se puede integrar con nuestro Active Directory? Sí, y es lo que recomendamos. El gateway verifica la identidad contra el directorio corporativo por OIDC o LDAP, así que las mismas cuentas y grupos que ya gestiona sistemas sirven para decidir quién accede a qué. Los servicios de detrás dejan de implementar esa comprobación.

¿Y si parte de nuestros sistemas está en nuestras oficinas y parte en la nube? Es exactamente este caso. El gateway vive en la nube y llega a los sistemas de las oficinas por VPN; quien llama desde fuera no sabe dónde está lo que llama. Y si mañana un sistema se mueve, nadie fuera se entera.

¿Qué pasa después de la entrega? Un gateway es una pieza de seguridad: se queda sin valor si nadie la actualiza. En este caso el proyecto se contrató junto con un mantenimiento mensual, con horas asignadas y compromiso anual. Es lo que proponemos siempre que entregamos infraestructura crítica.

Si quieres que lo miremos

Llevamos desde 2012 construyendo y cuidando plataformas para empresas que tienen sistemas en varios sitios y necesitan que hablen con el exterior sin miedo. Cuéntanos cuántos servicios tienes expuestos y cómo, y te decimos si una puerta te ahorra trabajo o si todavía no te hace falta.

Escríbenos y lo vemos.