El problema que resolvemos aquí es la incertidumbre de carga y rendimiento. Muchas veces, las pruebas sintéticas en Staging no logran replicar la complejidad del tráfico real: picos inesperados, colisiones de datos o latencias de red. El Shadow Deployment nos permite probar nuestra nueva versión en .NET contra el tráfico de producción real sin afectar la experiencia del cliente.
La Mecánica del «Espejo» de Tráfico
En un Shadow Deployment, el balanceador de carga o el API Gateway (como Azure API Management o un Ingress Controller en AKS) duplica cada petición entrante.
- La petición llega al balanceador.
- Se envía a la versión estable (Blue), que responde al usuario normalmente.
- Simultáneamente, se envía una copia de la misma petición a la versión nueva (Shadow).
- La respuesta de la versión Shadow se descarta o se almacena para análisis, pero nunca llega al usuario final.
Implementación Técnica en el Ecosistema Azure
Para ejecutar esto en Azure sin penalizar la latencia de la versión de producción, necesitamos un mecanismo de duplicación asíncrona:
- Azure API Management (APIM): Podemos usar políticas de enrutamiento para enviar una copia de la petición a un backend secundario.
- Service Mesh (Istio/Linkerd en AKS): Es la forma más común en microservicios. Istio permite configurar un Mirroring de tráfico de forma declarativa, enviando un porcentaje del tráfico al servicio «Shadow» sin esperar su respuesta.
- .NET y Azure Service Bus: En arquitecturas basadas en eventos, podemos hacer que el servicio Shadow se suscriba a los mismos temas (topics) que el servicio de producción para procesar los mensajes en paralelo y comparar resultados.
El Desafío de los «Efectos Secundarios»
El Shadow Deployment tiene un riesgo crítico: las mutaciones de datos. Si tu aplicación .NET procesa un pago o actualiza una base de datos, no puedes simplemente duplicar la petición, porque terminarías cobrando dos veces al cliente o corrompiendo los registros.
Solución : El servicio Shadow debe operar en un entorno de «solo lectura» o utilizar Mocks/Stubs para las salidas.
- Comparación de Resultados: La técnica ideal es registrar ambas respuestas (la de producción y la de sombra) en Azure Cosmos DB o Blob Storage y ejecutar un proceso de comparación (Diff) para identificar discrepancias en la lógica de negocio o en el rendimiento.
Notas
- Protege la Base de Datos: Asegúrate de que el entorno Shadow apunte a una base de datos de réplica o use un middleware en .NET que intercepte y descarte cualquier operación de escritura (INSERT, UPDATE, DELETE).
- Monitoreo de «Desviación» (Drift): Usa Application Insights para comparar la latencia de ambos servicios. Si el servicio Shadow es consistentemente más lento, tienes un problema de optimización que el Canary no te habría mostrado hasta que fuera tarde.
- Desacoplamiento asíncrono: La duplicación del tráfico debe ser «fire and forget». Si el servicio Shadow falla o es lento, esto nunca debe afectar el tiempo de respuesta del servicio principal.
Conclusión
El Shadow Deployment es la máxima expresión de la Observabilidad. Nos permite decir con total certeza: «Hemos probado la versión nueva con 10 millones de peticiones reales y se comportó exactamente igual que la actual».
Aunque es la estrategia más costosa en términos de recursos (estás ejecutando dos veces la misma carga) y complejidad de implementación, es la única que ofrece un riesgo cero para el usuario. Es el paso final antes de una migración masiva en sistemas donde la confianza no se negocia.
