Despliegues sin tiempo de inactividad y sin Kubernetes: métodos probados

Durante años, Kubernetes ha sido el martillo favorito del sector, y cada problema de despliegue de software parecía un clavo. Una de las razones por las que tanta gente recurre a él es simple: hace que desplegar sin tiempo de inactividad parezca tan fácil como pulsar un interruptor. Publicas una versión nueva, mantienes viva la anterior hasta que la nueva esté lista, dejas que el balanceador de carga redirija el tráfico y das el trabajo por terminado.

Sin embargo, los equipos ya ponían código en producción sin caídas mucho antes de que Kubernetes entrara en escena, y lo siguen haciendo hoy, a menudo con mucha menos complejidad, menos piezas móviles y una carga mental notablemente menor. Habla con ingenieros que lleven tiempo en primera línea y escucharás la misma idea una y otra vez: Kubernetes es cómodo, pero es solo un método entre varios, y no siempre el más adecuado.

En un entorno donde «usa Kubernetes y ya» se ha convertido en la respuesta automática, las llamadas «técnicas tradicionales» de despliegue están resurgiendo porque siguen funcionando con una eficacia sorprendente.

El balanceador de carga, el pilar clásico

La respuesta más habitual de los ingenieros veteranos suele llegar con un encogimiento de hombros, como si hablaran de la gravedad: ejecuta dos servidores y deja que el balanceador de carga haga su trabajo.

Este enfoque es más antiguo que muchos de los ingenieros cloud actuales. Levantas dos instancias (o veinte), colocas un balanceador de carga delante y actualizas una instancia cada vez. Mientras tu aplicación sepa cerrarse de forma educada (luego veremos ese detalle), puedes desplegar código nuevo sin que ningún usuario lo note.

No es llamativo, pero es infalible, una herramienta directa en la que se ha confiado durante décadas. «Llevamos más de 30 años haciendo esto», comentó un ingeniero, y la mayoría asintió al unísono.

Si utilizas NGINX o HAProxy, las funciones esenciales ya vienen integradas de serie: comprobaciones de salud, drenado de conexiones y conmutación limpia. Un usuario recordó incluso que NGINX puede intercambiar servidores de origen sin perder paquetes, de forma que el proceso se completa sin lágrimas ni contratiempos.

Despliegues blue-green, el patrón probado

Si los despliegues en Kubernetes representan el framework web moderno de la disponibilidad, los despliegues blue-green son el HTML 1.0 de esta técnica: simples, directos y perfectamente eficaces.

El guion es el siguiente:

• Despliegas la nueva versión en el entorno green (verde).
• Mantienes el entorno blue (azul) ejecutando la versión estable.
• Cuando green supera todas tus comprobaciones, conmutas el tráfico.
• Si algo se tuerce, devuelves el tráfico a blue.

Es el equivalente en despliegues a cambiar el puerto HDMI en tu televisor: poco esfuerzo, fiabilidad muy alta y cero tiempo de inactividad, salvo por los milisegundos que tarde el enrutamiento en actualizarse.

Muchos ingenieros confían plenamente en este patrón, y algunos incluso destacan la velocidad que alcanzan. Un profesional comentaba que solía conmutar flotas de más de mil servidores en menos de un minuto simplemente intercambiando enlaces simbólicos. Y hablando de enlaces simbólicos...

Enlaces simbólicos, el truco de UNIX que se niega a desaparecer

Si existiera un salón de la fama para los trucos de despliegue sencillos, este entraría a la primera.

Antes de los contenedores, antes de las plataformas de orquestación y antes de las herramientas modernas de gestión de configuración, las aplicaciones se desplegaban redirigiendo un enlace simbólico llamado current del directorio de la versión antigua al de la nueva.

El proceso funciona así:

1. Subes el código nuevo a /var/www/releases/version-329320
2. Actualizas el enlace simbólico current para que apunte a esa ruta
3. Reinicias (o recargas de forma limpia) el servidor web si hace falta
4. Lo celebras con algo de cafeína

Como actualizar un symlink es una operación atómica, el cambio es instantáneo. ¿Necesitas volver atrás? Apuntas current de nuevo a la carpeta anterior. No hay nada que reconstruir, nada que volver a subir a una plataforma de contenedores y ninguna necesidad de cerrar los ojos deseando que nada falle.

Quienes aplican este patrón hoy en día suelen combinarlo con herramientas como el módulo deploy_helper de Ansible, pero no hacen falta utilidades especiales. Un script en Bash funciona igual de bien, siempre que limpies versiones antiguas de vez en cuando.

DNS, factible en teoría y caótico en la práctica

Algunos ingenieros admitieron haber probado DNS para lograr despliegues sin tiempo de inactividad. La idea parece sencilla: defines un TTL bajo, cambias el registro A hacia el nuevo servidor y dejas que la propagación haga el resto.

En la práctica medio funciona, hasta que deja de hacerlo.

El comportamiento de la caché resulta impredecible entre proveedores de internet, redes corporativas, navegadores y dispositivos. Un ingeniero comentó que puede servir «si la complejidad es tu principal preocupación», pero otros aportaron rápidamente anécdotas complicadas sobre cambios de DNS que tardaron minutos, horas o incluso más tiempo en propagarse.

Sirve para entornos muy pequeños o proyectos informales. Sin embargo, utilizar DNS como balanceador de carga se parece a cocinar un pavo en el microondas: técnicamente es posible, pero los resultados son tremendamente irregulares.

Drenado de sesiones, el ingrediente clave para un apagado limpio

Ya utilices Kubernetes, un script propio o un conjunto de servidores veteranos en un armario, la regla de oro para evitar caídas es siempre la misma. Tu aplicación debe ser capaz de apagarse sin cerrarle la puerta a los usuarios en mitad de una petición.

El secreto reside en escuchar la señal SIGTERM, la orden que le indica a tu proceso que debe ir concluyendo tareas en lugar de morir de golpe. En los debates, los ingenieros insistían en que este detalle es el que realmente permite que los despliegues fluyan sin fricción.

En líneas generales, funciona así:

• La aplicación recibe SIGTERM
• Deja de aceptar peticiones nuevas
• Permite que las peticiones activas terminen
• Tras un periodo de gracia, el sistema finaliza el proceso si sigue abierto

Cualquier framework web actual admite este comportamiento de un modo u otro. Un ingeniero comentó que en Go se resuelve en apenas 2 líneas, Spring Boot lo trae integrado y los frameworks de Python también lo contemplan. Si tu aplicación gestiona SIGTERM con elegancia, puedes publicar actualizaciones casi en cualquier infraestructura.

Plataformas en la nube, despliegues continuos como servicio

Si prefieres servicios gestionados, la buena noticia es que prácticamente cualquier nube comercial tiene resueltos los despliegues sin caídas, y ninguno de ellos exige entender los detalles de la expulsión de pods.

Google Cloud Run levanta revisiones nuevas y deriva el tráfico de forma gradual. AWS ECS y Fargate llevan años realizando actualizaciones continuas mediante balanceadores de carga. Azure App Service te permite desplegar en ranuras de ensayo (staging slots) e intercambiarlas al instante como si barajaran cartas.

Todos estos servicios se apoyan en los mismos conceptos tradicionales utilizados durante décadas: múltiples instancias, balanceo de carga y comprobaciones de estado.

Docker sin Kubernetes sigue siendo totalmente viable

Muchos administradores ejecutan todo sobre Docker sin complicarse con Kubernetes. Suelen apoyarse en:

• Docker Compose con escalado manual
• Traefik como proxy inverso
• docker-swarm para orquestación ligera
• Actualizaciones progresivas sencillas contenedor por contenedor

Es exactamente el mismo principio que tener varios servidores, solo que cada «servidor» es un contenedor. Traefik en particular facilita la operativa porque solo envía tráfico a los contenedores que reportan un estado saludable.

Un ingeniero describió un flujo donde el sistema de CI/CD levanta una segunda copia de la imagen de la aplicación, espera a que esté saludable, le envía el tráfico, actualiza el resto del servicio y luego destruye la copia temporal. Suena sofisticado, pero la base es completamente tradicional.

La parte más delicada: las migraciones de bases de datos

Si existe un verdadero desafío en los despliegues sin tiempo de inactividad, son los cambios en la base de datos. El código nuevo espera columnas o tablas nuevas mientras el código antiguo todavía está atendiendo peticiones, y no puedes romper ninguno de los dos.

La recomendación general de los equipos experimentados siempre coincide: redacta migraciones que no invaliden el código anterior. Eso suele traducirse en:

• Añadir columnas nuevas en lugar de renombrar las existentes
• Dejar de escribir en columnas antiguas antes de eliminarlas
• Evitar cambios destructivos en el mismo despliegue
• Limpiar el esquema más adelante, cuando ya no quede ninguna versión antigua de la aplicación

Domina esta práctica y la mitad de la ansiedad asociada a los despliegues desaparecerá por completo.

Entonces, ¿necesitas realmente Kubernetes?

Si operas a escala global con decenas de microservicios comunicándose entre sí continuamente, desde luego: Kubernetes aporta un valor claro. Si coordinas un equipo numeroso que necesita herramientas y políticas homogéneas, justifica plenamente su inversión.

Pero si gestionas unas pocas aplicaciones web, tu flota se mide en servidores y no en continentes, y buscas una solución que funcione sin dedicar media vida al YAML, los métodos clásicos siguen siendo impecables. Balanceadores de carga, dos servidores, enlaces simbólicos, proxies inversos, SIGTERM, esquemas blue-green y comprobaciones de estado son mecanismos sencillos, predecibles y sólidos como una roca.

Los despliegues sin tiempo de inactividad y sin Kubernetes son una práctica cotidiana para multitud de equipos; el tipo de solución que los ingenieros llevan ejecutando en producción durante décadas sin aspavientos, y que seguirá estando ahí durante mucho tiempo.