En el monolito, obtener un informe que relacione clientes, pedidos y productos era una simple consulta con varios JOIN. En una arquitectura de microservicios, estos datos residen en bases de datos físicamente separadas, a menudo con motores distintos (SQL y NoSQL). Realizar un «JOIN de red» es ineficiente y peligroso para el rendimiento. Además, en entornos dinámicos de nube, las instancias de los servicios nacen y mueren constantemente, lo que hace que encontrarlos sea un reto técnico por sí mismo.
El Problema: El Rompecabezas de Datos y la Volatilidad de Red
Al distribuir la lógica y los datos, el equipo de desarrollo se enfrenta a obstáculos que no existían en el entorno centralizado:
- Dispersión de Información: Para mostrar una pantalla de «Detalle de Pedido», la aplicación necesita datos del Servicio de Usuario, el Servicio de Productos y el Servicio de Logística. Consultar cada uno por separado desde el cliente es lento y propenso a errores.
- JOINs de Aplicación Ineficientes: Intentar traer miles de registros de dos servicios para combinarlos en la memoria de un tercer servicio agota los recursos y satura el ancho de banda de la red interna.
- Localización de Servicios: En un cluster de Azure Kubernetes Service (AKS), los servicios cambian de dirección IP constantemente. Configurar direcciones fijas es imposible, lo que requiere un mecanismo automático para que el «Servicio A» sepa dónde está el «Servicio B» en todo momento.
La Solución: API Composition y Service Discovery
Para resolver la dispersión de datos, implementamos el patrón API Composition. Un servicio específico (que puede ser el propio API Gateway o un microservicio de agregación) recibe la consulta, dispara peticiones en paralelo a los servicios involucrados y fusiona los resultados en una única respuesta coherente. Si la consulta es demasiado pesada para este método, recurrimos a CQRS (visto en el Post 2), creando una vista pre-calculada en un servicio de búsqueda como Azure AI Search que ya contenga los datos unidos.
Para el problema de localización, Azure ofrece soluciones nativas de Service Discovery. En AKS, el servicio de DNS interno se encarga de traducir nombres lógicos a direcciones IP actuales. Si no usamos Kubernetes, herramientas como Azure API Management o App Service de Azure gestionan automáticamente el enrutamiento y el balanceo de carga, permitiendo que un servicio invoque a otro simplemente por su nombre, sin preocuparse por la infraestructura subyacente.
Notas para Azure y .NET
- Prioriza la Agregación en el Lado del Servidor: Evita que el cliente (Web/Móvil) haga el trabajo de unir los datos. Usa Azure API Management con políticas de agregación para presentar un modelo de datos simplificado y listo para consumir.
- Implementa Service Discovery Nativo: No reinventes la rueda. Si estás en AKS, confía en el CoreDNS del cluster. Si usas servicios más simples, utiliza Azure App Configuration para centralizar las URLs de los endpoints y que tus apps de .NET las consuman dinámicamente.
- Usa el Patrón Sidecar: Para funcionalidades transversales como el descubrimiento de servicios o la seguridad, utiliza el patrón Sidecar (común en Service Meshes como Istio dentro de Azure). Esto permite que tu código .NET se enfoque en la lógica de negocio mientras el Sidecar gestiona la comunicación.
Conclusión
En una arquitectura de microservicios, la dispersión de datos en bases de datos físicamente separadas y la volatilidad de las instancias en la nube eliminan la viabilidad de los tradicionales JOIN de SQL. Realizar consultas de red ineficientes o intentar combinar miles de registros en memoria agota los recursos y satura el ancho de banda, mientras que la naturaleza dinámica de entornos como Azure Kubernetes Service (AKS) hace que las direcciones IP cambien constantemente.
Para resolver este «rompecabezas», se implementa el patrón API Composition, donde un servicio de agregación o el propio API Gateway dispara peticiones en paralelo para fusionar resultados en una única respuesta coherente. En casos de alta complejidad, se recurre a CQRS con vistas precalculadas en herramientas como Azure AI Search. Complementariamente, soluciones nativas de Service Discovery en Azure y AKS permiten que los servicios se localicen automáticamente por nombre lógico, abstrayendo la infraestructura subyacente.
