En un mundo obsesionado con el Zero Downtime, el Recreate Deployment parece un tabú. Sin embargo, es la estrategia de despliegue más honesta que existe: detiene la versión actual (A), limpia el entorno y levanta la versión nueva (B). El problema que soluciona es la Incompatibilidad de Estado: cuando tu aplicación simplemente no puede permitir que dos versiones distintas toquen la misma base de datos o el mismo sistema de archivos al mismo tiempo.
El Mecanismo: Parada Total y Reinicio
A diferencia de todas las estrategias que hemos visto, aquí no hay convivencia. Es una secuencia lineal y destructiva:
- Shutdown: El balanceador de carga corta el tráfico y se apagan todas las instancias de la versión vieja.
- Deployment: Se despliegan los nuevos binarios o imágenes de contenedor.
- Startup: Se inicia la nueva versión y, una vez que los Health Checks pasan, se abre el tráfico.
¿Cuándo es la opción correcta en Azure y .NET?
Aunque no es ideal para una web de cara al público con millones de usuarios, el Recreate es el estándar de oro en los siguientes casos:
- Monolitos con Estado Pesado: Si tienes una aplicación .NET antigua migrada a Azure App Service que bloquea archivos en disco o mantiene conexiones exclusivas que impedirían que una segunda instancia inicie correctamente.
- Migraciones de Base de Datos Destructivas: Cuando el cambio en el esquema de Azure SQL es tan profundo que la versión vieja de la app lanzaría excepciones fatales de inmediato.
- Entornos de Desarrollo y QA: Donde el costo de mantener infraestructura duplicada (Blue-Green) o la complejidad de orquestación (Rolling) no justifica el esfuerzo.
- Sistemas de Procesamiento por Lotes (Batch): Donde es preferible pausar el procesamiento unos minutos para asegurar que la nueva lógica se aplique de forma atómica a todos los registros pendientes.
El Riesgo: El Abismo del Tiempo de Inactividad
El mayor peligro del Recreate Deployment es el Tiempo de Inicio (Bootstrapping time). Si tu aplicación .NET tarda 3 minutos en cargar configuraciones, inicializar el contenedor de dependencias y calentar los cachés, tus usuarios experimentarán un error 503 (Service Unavailable) durante todo ese tiempo.
En Azure, esto se gestiona a menudo con Azure Container Instances (ACI) o configurando el deployment en AKS con la estrategia type: Recreate. El orquestador se asegura de que no haya pods viejos antes de intentar crear los nuevos, evitando colisiones de volúmenes persistentes (Azure Disks) que no soportan múltiples montajes simultáneos (ReadWriteOnce).
Notas
- Página de Mantenimiento: Dado que habrá downtime, configura tu Azure Front Door o Application Gateway para mostrar una página estática elegante en lugar de un error de conexión genérico.
- Optimiza el Inicio: Si vas a usar Recreate, reduce el tiempo de arranque de tu app .NET. Usa ReadyToRun para acelerar el JIT y minimiza las tareas pesadas en el Startup.cs.
- Automatización de Parada: Asegúrate de que tu pipeline de Azure DevOps confirme que la versión anterior se ha detenido por completo antes de proceder, para evitar bloqueos en recursos compartidos.
Conclusión
El Recreate Deployment no es un error de ingeniería; es una elección de diseño. Es la estrategia para cuando prefieres un corte limpio y controlado antes que una transición impredecible. En la arquitectura moderna, saber cuándo no complicarse con un Canary o un Blue-Green es una señal de madurez y entendimiento de los límites de tu sistema.
