Desplegar sin downtime: por qué tu app no debería caer cada vez que actualizas

Es viernes a las 17:30. Alguien del equipo dice "voy a subir el fix rápido antes del fin de semana". Se despliega. La app se cae. El teléfono empieza a sonar.

Esta escena es más común de lo que debería. Y no pasa porque el equipo sea malo. Pasa porque muchos productos en producción siguen desplegando con el método más básico: parar, sustituir, arrancar. En el tiempo que tarda ese proceso, los usuarios ven errores, la app deja de responder o directamente desaparece.

Eso es downtime. Y desplegar sin downtime debería ser el estándar, no la excepción. Porque aunque la caída dure treinta segundos, para tus usuarios es una experiencia rota. Para tu negocio, son transacciones perdidas y un equipo que empieza a tener miedo de desplegar.

Qué es el downtime y por qué importa más de lo que parece

Downtime es cualquier periodo en el que tu aplicación no está disponible o no funciona correctamente para los usuarios. Puede ser una caída total (la app no responde) o parcial (funciona, pero con errores, lentitud o funcionalidades rotas).

Según datos de Gartner, el coste medio del downtime para una empresa es de unos 5.600 dólares por minuto. Esa cifra varía enormemente según el sector y el tamaño, pero el mensaje es claro: cada minuto cuenta.

Pero el coste no es solo económico directo. Hay un coste menos visible y más corrosivo.

Pérdida de confianza. Un usuario que ve un error 503 o una página en blanco no sabe si es un despliegue, un ataque o un fallo grave. Solo sabe que tu producto no funciona. Si pasa una vez, lo tolera. Si pasa cada semana, busca alternativas.

Miedo a desplegar. Cuando desplegar es arriesgado, el equipo despliega menos. Las releases se acumulan, cada despliegue es más grande y más peligroso, y el ciclo se retroalimenta. Es la definición de un círculo vicioso.

Ventanas de mantenimiento. Algunos equipos resuelven el problema programando despliegues en horarios de bajo tráfico: madrugadas, fines de semana. Funciona a corto plazo, pero destruye la calidad de vida del equipo y limita la capacidad de reaccionar rápido ante problemas.

Las estrategias que eliminan (o minimizan) el downtime

No hay una única forma de desplegar sin downtime. Hay varias estrategias, cada una con sus ventajas y sus requisitos. La elección depende de tu infraestructura, tu equipo y el nivel de riesgo que puedes asumir.

Rolling deployment

Es la estrategia más sencilla. En lugar de parar toda la aplicación, actualizas las instancias una por una. Mientras una instancia se actualiza, las demás siguen sirviendo tráfico. Cuando la primera termina, pasas a la siguiente.

El resultado: en todo momento hay instancias funcionando. El usuario no nota nada.

Cuándo encaja. Cuando tu aplicación corre sobre múltiples instancias (contenedores, servidores, pods de Kubernetes) y las versiones nueva y antigua pueden convivir brevemente. Es el estándar en la mayoría de orquestadores modernos. Kubernetes lo hace por defecto.

Cuándo no encaja. Si tu aplicación tiene estado en memoria que no se comparte entre instancias, o si la nueva versión incluye cambios en la base de datos incompatibles con la versión anterior. En esos casos, la convivencia de versiones puede generar errores.

Blue-green deployment

Mantienes dos entornos idénticos: blue (la versión actual) y green (la nueva versión). Despliegas la nueva versión en green, la pruebas, y cuando todo está listo, cambias el tráfico de blue a green. Si algo falla, vuelves a blue en segundos.

Cuándo encaja. Cuando necesitas certeza total antes de exponer a los usuarios. Es ideal para aplicaciones críticas donde un error en producción tiene un coste alto: ecommerce, fintech, salud.

Cuándo no encaja. Necesitas el doble de infraestructura (dos entornos completos corriendo a la vez). Para aplicaciones con muchos servicios interdependientes, mantener dos entornos sincronizados puede ser complejo y caro.

Canary deployment

Despliegas la nueva versión, pero solo la expones a un porcentaje pequeño de usuarios: un 5%, un 10%. Monitorizas las métricas (errores, latencia, comportamiento). Si todo va bien, aumentas el porcentaje gradualmente. Si algo falla, el impacto afecta solo a una fracción de los usuarios.

Cuándo encaja. Cuando quieres validar cambios con tráfico real antes de exponerlos a todos. Es la estrategia preferida de empresas como Netflix, Google y Spotify para cambios que afectan a la experiencia del usuario.

Cuándo no encaja. Requiere un sistema de routing que permita dirigir tráfico por porcentaje. También necesitas observabilidad buena: si no puedes medir el impacto del canary en tiempo real, no sirve de mucho.

Feature flags

Técnicamente no es una estrategia de despliegue, sino de activación. Despliegas el código nuevo en producción, pero desactivado. Cuando quieres, activas la funcionalidad para un grupo de usuarios, un porcentaje o todos. Si falla, la desactivas sin redesplegar.

Cuándo encaja. Cuando quieres separar el despliegue (acto técnico) de la release (acto de producto). Esto permite desplegar con frecuencia y activar funcionalidades de forma controlada. Herramientas como LaunchDarkly o Unleash lo hacen accesible.

Cuándo no encaja. Si no se gestionan bien, los feature flags se acumulan en el código y generan complejidad. Cada flag es una bifurcación lógica que hay que mantener. Sin disciplina para limpiarlos, se convierten en deuda técnica.

La pieza que falta: las migraciones de base de datos

Puedes tener una estrategia de despliegue impecable, pero si tu migración de base de datos rompe la compatibilidad con la versión anterior, vas a tener downtime.

Este es el punto que más equipos subestiman. Desplegar código es relativamente sencillo de hacer sin cortes. Migrar datos en caliente es otra historia.

La regla general: las migraciones deben ser compatibles hacia atrás. Esto significa que la versión antigua de la aplicación debe poder funcionar con la base de datos ya migrada. Si una migración renombra una columna, durante el despliegue la versión antigua buscará la columna con el nombre viejo y fallará.

La solución es desplegar en fases. Primero, una migración que añade la columna nueva sin eliminar la antigua. Segundo, un despliegue que usa la columna nueva. Tercero, una migración de limpieza que elimina la columna vieja. Es más trabajo, pero elimina el riesgo.

Equipos que trabajan con Django lo gestionan bien con las migraciones nativas del framework, siempre que se siga esta disciplina de fases. En otros stacks, herramientas como Flyway o Liquibase facilitan el mismo enfoque.

Qué necesita tu equipo para desplegar sin miedo

La estrategia de despliegue es la parte visible. Pero detrás hay requisitos que, si no están, ninguna estrategia funciona.

Pipeline de CI/CD automatizado. Si desplegar requiere ejecutar comandos a mano, conectarse a servidores por SSH o seguir un documento de 20 pasos, el riesgo de error humano es alto. Un pipeline automatizado garantiza que cada despliegue sigue los mismos pasos, con los mismos tests, siempre.

Tests que se ejecutan antes de cada despliegue. No hacen falta miles de tests. Hacen falta los tests correctos: los que validan que las funcionalidades críticas de tu aplicación funcionan. Si tu pipeline no tiene una suite de tests que bloquee el despliegue cuando algo falla, estás desplegando a ciegas.

Observabilidad en producción. Necesitas saber qué pasa después de desplegar. Métricas de latencia, tasas de error, uso de recursos. Herramientas como Datadog, Grafana o New Relic te dan visibilidad sobre el impacto real de cada despliegue. Sin observabilidad, un canary deployment no tiene sentido.

Capacidad de rollback rápido. Desplegar sin downtime no significa que nada pueda fallar. Significa que, cuando falla, puedes volver atrás en segundos, no en horas. Si tu rollback tarda más que el propio despliegue, tu red de seguridad no funciona.

La pregunta que de verdad importa

La pregunta no es "¿qué estrategia de despliegue uso?". La pregunta es: ¿con qué frecuencia puede desplegar tu equipo sin que nadie se ponga nervioso?

Si la respuesta es "una vez al mes, con mucho cuidado", tienes un problema de infraestructura y de confianza. Si la respuesta es "varias veces al día, sin pensarlo dos veces", tienes un equipo que ha invertido en las herramientas y prácticas correctas.

Según el informe DORA State of DevOps, los equipos de élite despliegan bajo demanda —a veces decenas de veces al día— con una tasa de fallos inferior al 5%. No es magia. Es automatización, observabilidad y estrategias de despliegue que eliminan el riesgo.

Desplegar no debería ser un evento. Debería ser una rutina. Y para que sea una rutina, tu app no puede caerse cada vez que lo haces.