3.16 Portales de API y mallas de servicios

Visión general y motivación

En el instante en que se fragmenta un solo programa en múltiples servicios, surge una pregunta nueva: ¿quién es responsable del tráfico entre ellos y del tráfico que entra desde fuera? Esa pregunta se puede resolver mal, esparciendo las mismas preocupaciones (autenticación, reintentos, temporizadores, límites de velocidad, registro de eventos) en cada servicio a mano, o bien resolverla con acierto, delegando esas preocupaciones en una capa compartida que cada servicio hereda sin esfuerzo. Este capítulo trata de dos de esas capas. Un API gateway se sitúa en la puerta principal y gestiona el tráfico que entra desde los clientes. Una malla de servicios se sitúa entre los propios servicios y gestiona el tráfico que fluye de uno a otro. Ambos resuelven problemas afines en ubicaciones distintas, y confundirlos es un error frecuente y costoso.

La industria designa ambas direcciones de tráfico con una metáfora de brújula. El tráfico norte-sur cruza la frontera del sistema: una aplicación móvil, un navegador o un proveedor externo que se conecta. El tráfico este-oeste permanece dentro del sistema: el servicio A llama al servicio B, que a su vez llama al servicio C para cumplir una sola petición. El API gateway es el especialista del norte-sur. La malla de servicios es la especialista del este-oeste. Mantener esa distinción nítida es la idea más útil de todo este capítulo, porque indica qué herramienta es responsable de cada política y evita que el mismo trabajo se haga dos veces.

Para equipos grandes, estas capas son el medio por el cual se aplica una política una sola vez en vez de cien. Cuando la autenticación, el cifrado en tránsito y el límite de velocidad viven en una capa compartida, una corrección de seguridad llega a todos los servicios el mismo día que se despliega la capa, en lugar de depender de cien listas de tareas pendientes. En entornos empresariales y gubernamentales, esa centralización suele ser el objetivo en sí: los auditores buscan un único punto de control demostrable donde se verifique el acceso y se cifre el tráfico, y un portal o una malla compartidos les ofrecen exactamente ese punto de ejecución de políticas. Este capítulo se apoya en los estilos arquitectónicos del capítulo 3.2, en las realidades de los sistemas distribuidos del capítulo 3.3 y en los fundamentos de red del capítulo 3.13, y los convierte en orientaciones concretas sobre quién gestiona el tráfico.

Principios fundamentales

Separar el tráfico norte-sur (portal) del este-oeste (malla); que cada uno asuma su dirección.
Delegar las preocupaciones transversales en una capa compartida para escribirlas una vez, no una vez por servicio.
Adoptar una malla de servicios solo cuando la cantidad de servicios haga que cablear cada uno individualmente resulte el mayor coste.
Definir un único punto de ejecución por cada preocupación; nunca permitir que el portal y la malla hagan el mismo trabajo a la vez.
Mantener los servicios ligeros: la plataforma se encarga del transporte, el servicio de la lógica de negocio.
Preferir una red basada en identidades y confianza cero sobre una basada en la posición en la red.
Comprar la complejidad operativa de una malla con los ojos bien abiertos y medir si de verdad compensa.

Recomendaciones

Comprender lo que hace un API gateway

Un API gateway es un único punto de entrada que se sitúa delante de los servicios y media cada petición que llega del mundo exterior. En su forma más simple, es un proxy inverso inteligente (un servidor que recibe peticiones de los clientes y las reenvía al backend correspondiente), pero un gateway se gana su nombre haciendo mucho más que reenviar. Enruta cada petición al servicio correcto en función de la ruta, el host o las cabeceras. Autentica al llamante (verificando quién es) y autoriza la petición (comprobando qué puede hacer), de modo que un servicio situado detrás pueda confiar en que la petición ya pasó por la puerta principal. Aplica el límite de velocidad (capa el número de peticiones por cliente en un período de tiempo) y las cuotas (capa el uso total en una ventana más larga) para que un cliente ruidoso o abusivo no prive a los demás.

Un gateway además transforma el tráfico. La transformación de peticiones reescribe cabeceras, traduce entre protocolos o adapta el formato de un cliente antiguo a las expectativas de un servicio nuevo. La composición de APIs permite que el gateway distribuya una única petición entrante a varios servicios y unifique sus respuestas en una sola, de modo que el cliente hace una llamada en lugar de seis. El soporte de versiones permite ejecutar v1 y v2 de una API en paralelo y enrutado a cada cliente la versión que espera, lo que da margen para evolucionar sin romper nada a nadie. Concentrar esas preocupaciones en el borde mantiene a los servicios enfocados en la lógica de negocio y ofrece un único lugar para observar, proteger y regular todo lo que entra. El diseño de las APIs que el gateway enmascara es objeto del capítulo 2.3, y las verificaciones de identidad que realiza se basan en el capítulo 4.7.

Usar el patrón backend para el frontend ante clientes divergentes

Una API general de propósito único a menudo sirve a una aplicación web, una aplicación móvil e integraciones de proveedores al mismo tiempo, y las sirve a todas con una media insuficiente. El cliente móvil desea payloads pequeños y pocos viajes de ida y vuelta porque el ancho de banda y la batería son escasos; el cliente web puede tolerar respuestas más verbosas y ricas; el proveedor quiere un contrato estable que nunca le sorprenda. El patrón backend para el frontend (BFF) resuelve esa tensión dotando a cada clase de cliente de su propio gateway fino, a la medida de sus necesidades, situado delante de los servicios compartidos que hay detrás.

Un BFF es un gateway con un público más acotado. El BFF móvil compone y poda las respuestas para que la app haga una sola llamada eficiente; el BFF web expone una forma más completa; el BFF del proveedor sostiene un contrato de evolución lenta y cuidadosamente versionado. Cada equipo puede evolucionar su propio BFF sin esperar a los demás, lo que a menudo es la verdadera ganancia, porque desacopla a los equipos de clientes unos de otros. El coste es más piezas móviles y cierta lógica duplicada entre BFF, así que conviene reservar este patrón para los casos en que las necesidades de los clientes divergan de verdad. Cuando todos los clientes quieren lo mismo, un solo gateway es más simple y mejor.

Comprender lo que hace una malla de servicios

Una malla de servicios gestiona el tráfico este-oeste entre los servicios y lo hace sin pedirles que modifiquen su código. La malla clásica funciona desplegando un proxy sidecar (un pequeño proceso proxy que se ejecuta junto a cada instancia del servicio e intercepta todo su tráfico de red) a cada instancia. El servicio cree que habla directamente con otro servicio; en realidad, habla con su sidecar local, que se encarga de la llamada de red real. Como cada petición fluye ahora a través de un proxy que la plataforma controla, la malla puede aplicar un comportamiento uniforme en cada servicio, en cada lenguaje, sin necesidad de una biblioteca compartida que mantener sincronizada.

¿Qué aplica? En primer lugar, TLS mutuo (mTLS), en el que ambos extremos de cada conexión presentan certificados y cifran el tráfico, de modo que las llamadas entre servicios están autenticadas y son privadas por defecto. En segundo lugar, la gestión de tráfico: la malla puede desviar un pequeño porcentaje de tráfico a una versión nueva para una publicación canaria, repartir el tráfico por cabeceras para pruebas, o espejarlo a un servicio de sombra. En tercer lugar, la resiliencia: reintentos, temporizadores y ruptura de circuitos (los patrones del capítulo 2.20) aplicados en la capa de plataforma, configurados por política y no codificados en cada servicio. En cuarto lugar, la observabilidad: como cada petición pasa por un proxy, la malla emite métricas, registros y trazas distribuidas consistentes para todo el tráfico entre servicios, alimentando las prácticas de observabilidad del capítulo 9.2. El autor del servicio no escribe nada de esto y obtiene todo.

Conocer el patrón sidecar y las alternativas sin sidecar

El modelo sidecar es elegante, pero no es gratis. Cada instancia del servicio ahora ejecuta un contenedor proxy adicional que consume memoria y CPU, y cada llamada añade dos saltos de red extra (hacia el sidecar local y desde el remoto), lo que suma latencia. Con un puñado de servicios, ese sobrecargo es imperceptible; a lo largo de miles de pods se convierte en una partida real de la factura de cómputo y del presupuesto de latencia. Ese coste ha impulsado una oleada de enfoques sin sidecar o sin proxy.

Dos direcciones importan. Una traslada las funciones de la malla desde un sidecar por pod a un proxy por nodo, de modo que muchos servicios en la misma máquina comparten un único proxy en lugar de ejecutar cada uno el suyo; esto sacrifica algo de aislamiento a cambio de una gran reducción del sobrecargo. La otra, la aproximación sin proxy, incrusta la lógica de la malla directamente en el servicio a través de una biblioteca ligera o del entorno de ejecución, eliminando los saltos extra por completo a cambio de una dependencia por lenguaje. Un desarrollo más reciente empuja algunas funciones de la malla al kernel del sistema operativo mediante eBPF (una tecnología para ejecutar programas aislados dentro del kernel de Linux), lo que puede aplicar políticas y recopilar telemetría con menos sobrecargo que un proxy en el espacio de usuario. No hace falta apostarlo todo a un ganador hoy. Hace falta saber que el impuesto del sidecar es real, que existen alternativas y que las decisiones de plataforma no deben cerrar la puerta a adoptarlas en el futuro. Estos patrones se asientan sobre los cimientos de orquestación de contenedores del capítulo 8.3.

Decidir cuándo una malla justifica su complejidad

Una malla de servicios es poderosa y genuinamente compleja de operar. Añade un plano de control que gestionar, proxies que actualizar, certificados que rotar y una capa nueva que depurar cuando una petición se pierde. Esa complejidad merece la pena cuando hay suficientes servicios como para que cablear esas preocupaciones a mano, por servicio y por lenguaje, cueste más que operar la malla. La señal aproximada es la escala y la diversidad políglota: decenas o cientos de servicios escritos en varios lenguajes, donde una biblioteca compartida para mTLS y reintentos sería una pesadilla de mantener consistente. A esa escala, una malla se amortiza por sí sola en uniformidad y seguridad demostrable.

La malla no justifica su complejidad cuando se dispone de un puñado de servicios, un solo lenguaje o un equipo pequeño. Para un sistema modesto, una buena biblioteca o marco puede ofrecer mTLS, reintentos y métricas con mucho menor carga operativa que una malla completa, y un portal sencillo junto con bibliotecas de cliente razonables suele cubrir todo lo necesario. Adoptar una malla porque está de moda, antes de que la escala lo exija, es una forma habitual de pasar un año operando infraestructura que resuelve un problema que no se tiene. Empieza por el portal, añade patrones de resiliencia en el código o en las bibliotecas, y acude a una malla cuando la cantidad de servicios y lenguajes haga que la aproximación por servicio individual sea la más cara. Es la misma disciplina del «¿justifica su complejidad?» que los capítulos sobre la nube y sistemas distribuidos (3.11 y 3.3) repiten una y otra vez.

Evitar el doble manejo donde portal y malla se solapan

Los portales y las mallas se solapan, y el solapamiento es donde los equipos se hacen daño. Ambos pueden hacer reintentos, ambos pueden aplicar temporizadores, ambos pueden verificar identidad, ambos pueden recopilar telemetría. Si el portal reintenta una petición tres veces y la malla también la reintenta tres veces en cada salto interno, un reintento de cliente puede multiplicarse en decenas de llamadas al backend y convertir un pequeño bache en una tormenta de reintentos. Si ambas capas aplican un temporizador y el interno es más largo que el externo, el externo se rinde mientras el interno sigue trabajando, desperdiciando esfuerzo en una respuesta que nadie leerá.

La solución es una división de trabajo clara, escrita y acordada. Asignar cada preocupación a exactamente una capa. El portal asume las preocupaciones norte-sur: autenticación del usuario final, límites de velocidad y cuotas externos, transformación de peticiones y composición de APIs para los clientes. La malla asume las preocupaciones este-oeste: mTLS entre servicios, reintentos internos y ruptura de circuitos, y el desvío de tráfico entre versiones de un servicio. Cuando una preocupación podría vivir en cualquiera de las dos, elegir un único propietario y hacer que la otra capa deje pasar. Configurar presupuestos de reintento y jerarquías de temporizadores de modo que un temporizador externo sea siempre más largo que el trabajo interno en el que espera. El objetivo es que cada petición tenga un único lugar que maneje cada preocupación y que ninguna petición sea reintentada, autenticada o registrada dos veces por accidente.

Tratar portal y malla como puntos de ejecución de políticas para la confianza cero

La razón más profunda de ejecutar estas capas es la arquitectura de seguridad. La confianza cero es el principio de que ninguna petición se confía por provenir de un lugar determinado; cada petición debe demostrar su identidad y su autorización, incluso dentro de la propia red. El modelo antiguo confiaba en todo lo que ya estuviera dentro del perímetro, lo que significaba que un servicio comprometido podía moverse con libertad. La confianza cero sustituye la confianza basada en la posición de red por una confianza basada en la identidad en cada salto, y los portales y las mallas son los puntos de ejecución naturales donde esa identidad se verifica.

El portal es el punto de ejecución de la identidad externa: verifica al usuario final o al proveedor antes de que nada alcance a los servicios. La malla es el punto de ejecución de la identidad de la carga de trabajo: cada servicio obtiene una identidad criptográfica, el mTLS la demuestra en cada llamada, y la política decide qué servicios pueden hablar entre sí. Juntos ofrecen defensa en profundidad, en la que una petición se comprueba en el borde y de nuevo entre servicios, de modo que el compromiso de un servicio no otorga libre movimiento al resto. En despliegues multiclúster y multi-región, una malla puede extender esta tela de identidad más allá de las fronteras de un clúster, de modo que un servicio en un clúster se autentica con otro en un clúster distinto con las mismas garantías de mTLS que usa localmente, ofreciendo una red de confianza cero coherente incluso cuando la huella se expande. Los fundamentos de identidad aquí se conectan directamente con el capítulo 4.7.

Compromisos: ventajas e inconvenientes

Enfoque	Ventajas	Inconvenientes
API gateway	Un único lugar para autenticación, límites de velocidad, composición y versionado	Un punto único de estrangulamiento que hay que escalar y mantener con alta disponibilidad
Backend para el frontend	Cada cliente obtiene una API a su medida, que evoluciona de forma independiente	Más portales que operar; lógica duplicada entre BFF
Malla de servicios (sidecar)	mTLS, reintentos y observabilidad uniformes sin cambiar el código	Sobrecargo del proxy, latencia y un plano de control que operar
Malla sin sidecar / sin proxy	Menor sobrecargo y latencia que los sidecars por pod	Menos madurez; aislamiento más débil o dependencia por lenguaje
Resiliencia basada en bibliotecas	Simple de operar; sin infraestructura adicional	Duplicación por lenguaje; difícil de mantener consistente a escala
Malla entre clústeres	Identidad de confianza cero coherente en todas partes	Complejidad operativa y de red significativa

La tensión central es entre uniformidad y coste operativo. Una capa compartida compra consistencia, seguridad demostrable y políticas que se escriben una sola vez, pero es un sistema real que hay que ejecutar, escalar, proteger y depurar, y se interpone en el camino de cada petición. Resolver esa tensión mediante la escala y la necesidad. Un portal casi siempre se amortiza en cuanto hay clientes externos, porque las preocupaciones que centraliza son las que no se pueden esquivar. Una malla se amortiza después, cuando la cantidad de servicios y lenguajes hace que cablear cada uno individualmente sea la vía más cara. Por debajo de ese umbral, las bibliotecas junto con un portal ofrecen la mayor parte del beneficio por una fracción del coste. Por encima, la uniformidad de la malla justifica su peso. El error en ambas direcciones es adoptar por moda en lugar de por necesidad: una malla demasiado temprano es un año de tareas mecánicas que no resuelven nada, y una malla omitida demasiado tarde son cien implementaciones artesanales, inconsistentes, de mTLS.

Preguntas para debatir con el equipo

¿Para cada preocupación transversal (autenticación, reintentos, temporizadores, límite de velocidad, cifrado, telemetría), qué capa única la asume, y puede cada miembro nombrar al responsable sin adivinar? Esta es la pregunta que impide el doble manejo, y la mayoría de los equipos nunca la han respondido de forma explícita, de modo que la respuesta varía según el servicio y según la persona. Llevar una lista concreta de preocupaciones en el lado izquierdo y las capas (biblioteca de cliente, portal, malla, servicio individual) en la cabecera, y rellenar la cuadrícula juntos. Los lugares donde dos casillas están marcadas para una misma preocupación son las tormentas de reintento y las inversiones de temporizador que esperan su turno. Las filas vacías son las preocupaciones que nadie está manejando en absoluto. El entregable es una sola tabla acordada, publicada donde cada equipo puede verla, que diga exactamente qué capa asume cada preocupación y que las demás la dejen pasar. Esa tabla vale más que cualquier cantidad de configuración de portal o malla, porque es lo que impide que las dos capas se enfrenten.
¿De verdad hay suficientes servicios y diversidad de lenguajes para justificar una malla de servicios, o se está a punto de comprar un plano de control para resolver un problema que no existe? Una malla es un compromiso operativo serio, y la respuesta honesta para muchos equipos es que una buena biblioteca junto con un portal los serviría mejor hoy. Llevar el número real de servicios, la cantidad de lenguajes en los que están escritos y una evaluación honesta de cuánto daña realmente la lógica de red duplicada en este momento. Y luego traer el otro lado: quién operará la malla, actualizará sus proxies, rotará sus certificados y será llamado a medianoche cuando enrute mal una petición. Si el dolor del cableado por servicio es menor que el coste de operar la malla, ahí está la respuesta, y es esperar. Si se está ahogando en mTLS y reintentos inconsistentes a través de decenas de servicios políglotas, la malla justifica su mantenimiento. La cuestión es decidir con evidencia, no con lo que una charla de congreso hizo parecer a la malla.
¿Dónde está hoy el límite de confianza cero del sistema, y qué ocurre si un servicio interno se compromete? Muchos sistemas siguen confiando en todo lo que ya esté dentro de la red, lo que significa que un servicio comprometido puede moverse lateralmente y alcanzar todo lo demás, y los equipos a menudo lo descubren solo durante un incidente. Recorrer el radio de daño con honestidad: si un atacante controla uno de los servicios, ¿a qué puede llamar, qué puede leer y qué lo detiene? Llevar la respuesta actual sobre cómo se autentican y cifran las llamadas entre servicios, y ser específico sobre cuáles están protegidas por mTLS y cuáles son de texto plano confiadas por estar en la misma red. La acción que sigue es un plan deliberado de acceso basado en identidad en cada salto, con el portal verificando la identidad externa y la malla (o un equivalente) verificando la identidad de la carga de trabajo, de modo que un compromiso se contenga en lugar de ser catastrófico. Incluso si no se está preparado para ejecutar una malla completa, nombrar dónde está realmente la frontera de confianza es el primer paso honesto.
Si la capa del API gateway fallara ahora mismo, ¿cuánta parte del sistema quedaría inoperante, y se ha probado ese fallo en lugar de darlo por descartado? El portal centraliza tanto que su caída deja inoperante todo lo que hay detrás, y los equipos grandes tienden a invertir poco en su redundancia precisamente porque funciona en silencio hasta que no lo hace. Pesar las presiones opuestas: un único portal simple es fácil de razonar y barato de operar, mientras que una capa escalada horizontalmente y multi-zona cuesta más y añade su propia configuración de conmutación por error. Llevar cifras reales al debate: cuántas instancias se ejecutan hoy, en cuántas zonas de disponibilidad, cuál es el tiempo de conmutación y cuándo se hizo por última vez un simulacro que mató el portal a propósito. Para plataformas empresariales o gubernamentales con compromisos de disponibilidad o niveles de servicio normativos, añadir la sanción contractual o regulatoria por una interrupción, porque una puerta principal sin redundancia es un riesgo de disponibilidad que se ha aceptado en silencio en nombre de cada servicio y cada ciudadano que hay detrás.
¿Se ha medido el impuesto del sidecar que la malla cobra de verdad, y hay un plan para las alternativas sin sidecar y basadas en eBPF, o se está pagando a ciegas? A escala, el sobrecargo por pod en cómputo y latencia deja de ser invisible y se convierte en una partida real del presupuesto, y sin embargo muchos equipos ejecutan miles de sidecars sin medir jamás el coste. La tensión está entre la madurez y el aislamiento del modelo sidecar, por un lado, y el menor sobrecargo de los proxies por nodo, las bibliotecas sin proxy o los enfoques kernel basados en eBPF, por el otro, que son más recientes y sacrifican algo de aislamiento o añaden una dependencia por lenguaje. Llevar las cifras medidas: memoria y CPU consumidas por los proxies en toda la flota, la latencia de cola añadida por salto y qué fracción de la factura de cómputo representa la malla. Para una gran empresa que ejecuta la malla a lo largo de miles de pods, o una plataforma gubernamental bajo escrutinio presupuestario, esta es una decisión de gasto que la supervisión acabará preguntando, así que conocer el impuesto y si las decisiones de plataforma mantienen abiertas las opciones más económicas es una diligencia básica.
¿Cada clase de cliente necesita realmente su propio backend para el frontend, o se está a punto de duplicar lógica entre portales para clientes que en realidad quieren lo mismo? El patrón BFF desacopla a los equipos de clientes y permite a cada uno evolucionar un contrato a su medida, pero cada BFF nuevo es otro portal que hay que ejecutar, proteger y mantener sincronizado, y la lógica duplicada entre ellos se convierte en una carga de mantenimiento silenciosa. Las consideraciones en tensión son la autonomía del equipo y la eficiencia específica del cliente, frente al coste operativo y la deriva de muchos portales casi idénticos. Traer evidencia de cuánto divergen de verdad las necesidades de los clientes: tamaños de payload, número de viajes de ida y vuelta, ritmo de versionado y con qué frecuencia el cambio de un cliente habría bloqueado a otro bajo un portal único compartido. En una organización grande con muchos equipos de clientes, o una plataforma gubernamental que sirve simultáneamente una aplicación web pública, una app móvil e integraciones de proveedores, la pregunta honesta es si la divergencia justifica la proliferación, porque un BFF por cliente que todos quieren la misma forma es dispersión que se pagará durante años.

Mirada sectorial

Startup. Desplegar un API gateway y saltarse la malla. Con un puñado de servicios y un equipo diminuto, un único portal gestiona la autenticación, los límites de velocidad y la composición, mientras una biblioteca de cliente compartida ofrece mTLS y reintentos por una fracción del coste de un plano de control. El recurso más escaso es la atención del equipo de ingeniería, así que una malla que no se puede operar es una lastre, no una ventaja. Mantener el portal lo suficientemente redundante como para sobrevivir a la caída de un nodo, y revisar la cuestión de la malla solo cuando la cantidad de servicios y la diversidad de lenguajes la exijan de verdad.

Pyme. No hay equipo de plataforma para operar una malla, así que apoyarse en lo que la plataforma de hospedaje o el producto de gateway ofrece de serie: TLS gestionado, límite de velocidad integrado y un portal alojado en lugar de uno que se tenga que parchear uno mismo. Enmarcar la decisión como comprar frente a construir, y comprar, porque un API gateway gestionado cuesta menos que las horas de ingeniero necesarias para operar el propio. Tratar el cifrado interno entre servicios como una función que la plataforma proporciona, no como un proyecto que hay que dotar de personal.

Empresa. Con cientos de servicios a lo largo de muchos equipos y lenguajes, una malla justifica su complejidad, y el trabajo de verdad es la gobernanza: una división de trabajo escrita para que el portal y la malla nunca manejen la misma preocupación en doble, mTLS y telemetría uniformes, y un equipo de plataforma que asuma las actualizaciones de proxies y la rotación de certificados. Los auditores quieren un único punto de control demostrable para el acceso y el cifrado, así que estandarizar la interfaz y hacer que las políticas sean algo que los equipos heredan, no que reimplementan. Gestionar el impuesto del sidecar como una línea real de presupuesto y mantener abiertas las opciones sin sidecar para no quedar bloqueado de aproximaciones más económicas en el futuro.

Administración pública. Las reglas de contratación, la transparencia y la rendición de cuentas pública moldean la arquitectura. Tratar el portal y la malla como la columna vertebral de confianza cero que los reguladores exigen: cada ciudadano y cada proveedor autenticados en la puerta principal, cada llamada interna autenticada y cifrada por identidad de la carga de trabajo, y una pista de auditoría en cada punto de ejecución que demuestre dónde se verificó el acceso y dónde se cifró el tráfico. Preferir estándares abiertos y configuración portable sobre la vinculación propietaria que las reglas de contratación pueden prohibir, y publicar, en la medida que proceda, cómo la plataforma protege los datos del ciudadano al cruzar cada frontera.

Ejemplos

Startup. Una startup de doce personas ejecuta ocho servicios detrás de un único API gateway. El portal asume todo el trabajo norte-sur: autentica a los usuarios con una verificación de token, aplica límites de velocidad por plan para que los usuarios de nivel gratuito no saturen el sistema, y compone un par de endpoints verbosos en llamadas únicas aptas para móvil. Para el tráfico este-oeste renuncian deliberadamente a una malla, porque ocho servicios en dos lenguajes no justifican un plano de control. En su lugar obtienen mTLS y reintentos de una biblioteca de cliente compartida y de la gestión de certificados integrada de su plataforma, y recogen trazas con un agente ligero. Cuando más adelante añaden un cliente móvil dedicado con necesidades más estrictas de payload, introducen un backend para el frontend móvil junto al portal web existente. Revisan la cuestión de la malla cada año y siguen decidiendo, con acierto, que aún no han cruzado el umbral donde se amortizaría.

Empresa. Un banco multinacional ejecuta varios cientos de servicios a lo largo de muchos equipos y lenguajes, y aquí una malla de servicios justifica su complejidad. Cada servicio obtiene una identidad de carga de trabajo y mTLS por defecto, de modo que todo el tráfico interno está autenticado y cifrado sin que ningún equipo escriba código criptográfico, lo que satisface tanto a la organización de seguridad como a los auditores que buscan un único punto de control demostrable. La malla aplica reintentos, temporizadores y ruptura de circuitos de forma uniforme por política, y desvía el tráfico gradualmente para publicaciones canarias, de modo que un despliegue defectuoso toca al uno por ciento de los usuarios antes de tocar a todos. Una capa de API gateways enmascara el tráfico externo y de proveedores, asumiendo la autenticación, las cuotas y el versionado, con una norma escrita y firme de que los reintentos internos viven solo en la malla y los límites de velocidad externos solo en los portales, de modo que las dos capas nunca manejen una petición en doble. La telemetría coherente de cada proxy alimenta una plataforma central de observabilidad que permite a un ingeniero de guardia seguir una petición a través de decenas de saltos de servicio.

Administración pública. Una agencia tributaria nacional moderniza una plataforma de declaración orientada al ciudadano y trata el portal y la malla como la columna vertebral de una arquitectura de confianza cero que los reguladores exigen. Un API gateway es la puerta principal controlada: cada ciudadano y cada proveedor se autentican y autorizan allí, los límites de velocidad externos protegen el sistema durante el pico de la fecha límite, y los formatos de clientes antiguos se transforman en el borde para que las integraciones heredadas sigan funcionando. Detrás, una malla de servicios otorga a cada servicio interno una identidad criptográfica y aplica mTLS en cada llamada, de modo que ningún servicio se confía solo por estar dentro de la red, y la política de acceso lista explícitamente qué servicios pueden llamar a cuáles. Como la plataforma abarca varios centros de datos para la resiliencia, la malla extiende las mismas garantías de identidad y cifrado entre clústeres, ofreciendo una red de confianza cero coherente a nivel nacional. Cada punto de ejecución emite una pista de auditoría, para que la agencia pueda demostrar a los organismos de supervisión exactamente dónde se verificó el acceso y dónde se cifró el tráfico.

Casos de negocio: motivaciones, retorno y coste total de propiedad

El retorno de un portal es fácil de ver y suele ser grande. En lugar de que cada servicio reimplemente la autenticación, el límite de velocidad y el registro de peticiones, se construyen una vez en el borde y cada servicio los hereda. Una corrección de seguridad o una nueva política de límite de velocidad se despliega en una sola vez en lugar de en cien, lo que acorta el tiempo para cerrar una vulnerabilidad y reduce el coste de cada auditoría, porque hay un único lugar donde inspeccionar. Las funciones de composición y versionado reducen los viajes de ida y vuelta del cliente y permiten evolucionar APIs sin romper a los llamantes, lo que disminuye tanto los costes de latencia como el impuesto de coordinación entre equipos. Para casi cualquier sistema con clientes externos, un portal se amortiza rápidamente.

La malla de servicios tiene un caso de negocio más sutil, porque su coste total de propiedad es real y continuo. Se paga por el cómputo y la latencia de los proxies, por los ingenieros que operan el plano de control y por la curva de aprendizaje de depurar una capa nueva. Ese coste se justifica cuando la alternativa (implementaciones por servicio y por lenguaje de mTLS, reintentos y telemetría) sería mayor y, peor aún, inconsistente de formas que crean brechas de seguridad y averías. A gran escala, la malla convierte cien soluciones frágiles y artesanales en una única y uniforme y demostrable, y el retorno se manifiesta en menos incidentes de seguridad, despliegues más seguros mediante el desvío de tráfico y una observabilidad drásticamente mejor. Por debajo de esa escala, el cálculo honesto suele favorecer las bibliotecas y un portal, y el movimiento disciplinado es esperar. Para presentar el caso a la dirección, vincular el portal con las métricas que ya跟踪: tiempo para remediar vulnerabilidades, coste de auditoría, sobrecoste de coordinación de APIs, y vincular la malla con el contención de incidentes de seguridad, la seguridad del despliegue y el coste de la duplicación políglota que reemplaza.

Antipatrones y trampas

Malla antes de necesitarla: adoptar una malla completa con un puñado de servicios, comprando un plano de control para resolver un problema que aún no existe.
Reintentos en doble: el portal y la malla reintentan ambos, de modo que una llamada de cliente se multiplica en una tormenta de reintento al backend que amplifica una avería.
Inversión de temporizador: un temporizador interno más largo que el externo, de modo que el llamante se rinde mientras el llamado sigue trabajando en una respuesta que nadie leerá.
El portal como monolito: meter lógica de negocio en el portal hasta que se convierte en un cuello de botella compartido que cada equipo debe coordinar para cambiar.
Punto único de fallo: ejecutar una sola instancia del portal sin redundancia, de modo que la caída de la puerta principal inutiliza cada servicio que hay detrás.
Confianza en la red: tratar todo lo que esté dentro del perímetro como seguro, de modo que un servicio comprometido pueda moverse lateralmente y alcanzar todo.
Propiedad solapada: no hay una división de trabajo escrita, de modo que la misma preocupación se maneja en ambas capas por accidente y nadie sabe cuál es la autoritativa.
Dispersión de BFF: desplegar un backend para el frontend por cada cliente cuando todos quieren lo mismo, multiplicando portales y duplicando lógica sin ganancia.
Ignorar el impuesto del sidecar: desplegar miles de sidecars sin medir el sobrecargo de cómputo y latencia, y luego preguntarse a dónde fue el presupuesto.

Modelo de madurez

Nivel 1, Iniciar: Los servicios se hablan directamente sin capa compartida. La autenticación, los reintentos y los temporizadores se codifican a mano por servicio y son inconsistentes. El tráfico interno suele ser texto plano y se confía por estar en la red, y no hay un único lugar para aplicar políticas ni observar el tráfico. Las decisiones son reactivas, tomadas servicio a servicio a medida que surgen los problemas.
Nivel 2, Desarrollar: Un API gateway enmascara el tráfico externo y centraliza la autenticación, el límite de velocidad y el enrutado, pero las preocupaciones este-oeste se manejan con bibliotecas compartidas de adopción desigual. Algunos servicios tienen mTLS; muchos no. Los equipos reconocen la distinción entre norte-sur y este-oeste, pero la responsabilidad es informal y las prácticas varían de un equipo a otro.
Nivel 3, Estandarizar: Las preocupaciones norte-sur y este-oeste se separan con nitidez mediante una división de trabajo escrita que se aplica en toda la organización. El portal asume la identidad externa, las cuotas y la composición; una malla o una capa de bibliotecas consistente asume el mTLS interno, los reintentos y la telemetría. Los solapamientos se resuelven para que ninguna preocupación se maneje en doble, el tráfico interno está cifrado y con verificación de identidad por defecto, y el estándar está documentado y aplicado, no dejado a la discreción de cada equipo.
Nivel 4, Gestionar: La capa de tráfico se mide y controla frente a líneas de base. Se registra el impuesto del sidecar en cómputo y latencia de cola por salto, la disponibilidad del portal y la malla frente a presupuestos de error, los incidentes de amplificación de reintento e inversión de temporizador, la cobertura de mTLS como porcentaje de las llamadas internas y el tiempo para empujar un cambio de política en toda la flota. Las métricas gobiernan las decisiones: una actualización de proxy, un nuevo presupuesto de reintento o una regla canaria se evalúan con datos frente a una línea de base, no con intuición, y cualquier desviación del estándar dispara una corrección.
Nivel 5, Orquestar: Portal y malla son puntos de ejecución de políticas para una arquitectura de confianza cero madura, con identidad verificada en cada salto entre clústeres y regiones. El desvío de tráfico impulsa entregas progresivas seguras, la observabilidad es uniforme y rica, y la organización evalúa y adopta continuamente aproximaciones sin sidecar, sin proxy y basadas en eBPF donde se amortizan. La capa de tráfico está integrada con la seguridad, la entrega y la planificación de capacidad, y se adapta a medida que cambian la escala, los lenguajes y el panorama de riesgo.

Ideas para la reflexión

Si el único API gateway cayera ahora mismo, ¿cuántos servicios quedarían inalcanzables y cuál es el plan para hacer la puerta principal redundante?
¿Qué preocupación del sistema se maneja actualmente tanto en el portal como en un servicio (o en una biblioteca), y cómo se demostraría que no se está manejando en doble?
¿A cuántos servicios y lenguajes el equipo acordaría que una malla ha justificado por fin su complejidad, y qué distancia hay de esa línea?
Si un atacante comprometiera un servicio interno mañana, ¿a qué otros servicios podría alcanzar y qué verificación de identidad lo detendría?
¿Son los enfoques de malla sin sidecar o basados en eBPF lo suficientemente maduros para la plataforma actual, y qué se mediría para decidir?
¿Cada uno de los clientes divergentes necesita realmente su propio backend para el frontend, o se está a punto de duplicar lógica que podría seguir compartida?

Ideas clave

Separar el tráfico norte-sur (gestionado por un API gateway) del este-oeste (gestionado por una malla de servicios); cada uno asume su dirección, y confundirlos provoca doble manejo.
Un portal centraliza el enrutado, la autenticación, la autorización, el límite de velocidad, las cuotas, la transformación de peticiones, la composición y el versionado, de modo que los servicios permanecen ligeros y las políticas viven en un único lugar.
Una malla de servicios ofrece mTLS, desvío de tráfico, reintentos y ruptura de circuitos a nivel de plataforma y observabilidad uniforme sin modificar el código del servicio, clásicamente mediante proxies sidecar.
Adoptar una malla solo cuando la cantidad de servicios y lenguajes haga que cablear cada uno sea la vía más cara; por debajo, las bibliotecas junto con un portal ganan, y el impuesto del sidecar es suficiente como para vigilarlo.
Tratar portal y malla como los puntos de ejecución de políticas de una arquitectura de confianza cero, asignar cada preocupación transversal a exactamente una capa y verificar la identidad en cada salto entre clústeres.

Referencias y lecturas complementarias

Sam Newman, Building Microservices: Designing Fine-Grained Systems
Chris Richardson, Microservices Patterns: With Examples in Java
Lee Calcote y Zack Butcher, Istio: Up and Running
Ken Owens, Alois Reitbauer y otros; el CNCF y su paisaje de computación nativa de la nube y la documentación de mallas de servicios
Evan Gilman y Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Scott Rose, Oliver Borchert, Stu Mitchell y Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
Susan Fowler, Production-Ready Microservices