El problema fundamental que busca resolver el Rolling Deployment es la rigidez de los recursos. En entornos donde no podemos (o no queremos) duplicar el costo de la infraestructura como sucede en el Blue-Green, el Rolling Update propone una sustitución pieza por pieza. Es la estrategia ideal para sistemas con cientos de microservicios donde la eficiencia del clúster es prioridad.
El Concepto: Sustitución por Oleadas
En un Rolling Deployment, la nueva versión de la aplicación se despliega en «oleadas». Imagina que tienes un cluster de Azure Kubernetes Service (AKS) con 10 réplicas de un servicio de facturación en .NET. En lugar de detener las 10 y arrancar 10 nuevas (lo que causaría un downtime total), el orquestador actualiza, por ejemplo, 2 réplicas a la vez.
Este proceso continúa hasta que todas las instancias ejecutan la versión nueva. Lo crítico aquí es la ventana de coexistencia: durante el tiempo que dure el despliegue, convivirán en tu red balanceada tanto la versión estable (v1) como la candidata (v2).
Configuración de Precisión en Azure y .NET
Para que esto no sea un caos de errores intermitentes, los ingenieros de Microsoft deben dominar dos palancas técnicas en sus manifiestos de despliegue (YAML):
- Max Surge (Exceso Máximo): Es el número de instancias adicionales que Azure puede levantar por encima de tu capacidad deseada. Si tu maxSurge es 25%, en nuestro ejemplo de 10 pods, Azure levantará 3 pods nuevos de .NET 9 antes de matar los de .NET 8. Esto garantiza que nunca bajes de tu capacidad nominal de procesamiento.
- Max Unavailable (No Disponibilidad Máxima): Define cuántos pods pueden estar caídos durante el proceso. Si lo pones en 0, aseguras que siempre haya al menos el 100% de la capacidad contratada atendiendo peticiones.
El middleware de .NET: Tu mejor aliado
En una aplicación .NET, el éxito del Rolling Update depende del Health Check Middleware. Si el contenedor se reporta como «Healthy» apenas inicia el proceso, pero el DbContext de Entity Framework aún no ha calentado el pool de conexiones, Kubernetes empezará a enviarle tráfico real y los usuarios verán errores de «Connection Timeout».
- Recomendación: Implementa un ReadinessProbe que no solo devuelva un 200 OK, sino que valide dependencias críticas (SQL, Redis, Key Vault) antes de marcarse como listo.
El Desafío: Inconsistencia de Versiones y Sesiones
El mayor riesgo del Rolling Deployment es la Incompatibilidad Transitoria. Como las versiones v1 y v2 conviven, un usuario que navega por tu web podría hacer una petición que caiga en v1 y la siguiente (por balanceo de carga) en v2.
Si v2 cambió el esquema de un objeto JSON en la API, o si v2 utiliza una clave de cifrado distinta para las cookies de autenticación, el usuario experimentará errores inexplicables o cierres de sesión. En Azure, esto se mitiga usando Application Gateway con Affinity Cookies (sesiones pegajosas), aunque lo ideal es diseñar APIs que sean compatibles hacia atrás y hacia adelante (Forward & Backward Compatibility).
La Gestión del Rollback
¿Qué pasa si la oleada 3 de 10 empieza a fallar? A diferencia del Blue-Green, donde el rollback es un switch instantáneo, aquí el rollback es un «Rolling Back»: el orquestador debe revertir el proceso, reemplazando las instancias v2 fallidas por las v1 estables.
En Azure DevOps Pipelines, esto se automatiza mediante el uso de Deployment Gates. Si las métricas de Application Insights detectan un aumento en excepciones NullReferenceException tras la primera oleada, el pipeline detiene el despliegue automáticamente, evitando que el error se propague al 100% de la infraestructura.
Notas
- Ajusta el paso (Batch Size): En entornos de bajo tráfico, puedes usar un maxSurge alto para terminar rápido. En sistemas de alto volumen, usa pasos pequeños (ej. 10%) para monitorear el impacto con cautela.
- Graceful Shutdown: Configura tu aplicación .NET para manejar el SIGTERM. Cuando Kubernetes decide matar una instancia vieja, la app debe tener unos segundos (vía IHostApplicationLifetime) para terminar de procesar las peticiones en curso antes de cerrarse.
- Monitoreo de «Long Tail»: No mires solo el promedio de errores. Durante un Rolling Update, busca anomalías en el percentil 99 (P99) de latencia, que suele ser donde se esconden los problemas de inicialización de las nuevas instancias.
Conclusión: El Equilibrio entre Costo y Riesgo
El Rolling Deployment es la estrategia de madurez por excelencia. No requiere el músculo financiero de duplicar servidores, pero exige una disciplina técnica impecable en el manejo de versiones y salud de la aplicación.
En el contexto de Azure Container Apps o AKS, es la forma más natural de operar. Permite que el sistema respire, se actualice y se cure de forma orgánica. Si tu aplicación .NET está diseñada para ser stateless (sin estado) y tus contratos de API son robustos, el Rolling Deployment ofrece una experiencia de usuario fluida sin afectar la rentabilidad del proyecto.
