Módulo 7: Gitops Beyond Terraform

5. Estrategias de despliegue de aplicación, nombradas

Descripción

Cada vez que apply.yml corrió en esta guía, el resultado fue simple de razonar: la infraestructura pasó de un estado a otro estado nuevo, de una sola vez, sin que existieran "dos versiones" del bucket andes-cargo-shipment-docs corriendo en paralelo mientras alguien decidía cuál se queda. Ese problema —tener temporalmente dos versiones de algo corriendo al mismo tiempo, y decidir cómo y cuándo pasar el tráfico real de usuarios de una a la otra sin downtime— es un problema que Terraform, en esta guía, nunca tuvo. Es, en cambio, el problema central de desplegar una aplicación: un contenedor, una API, un frontend, algo con réplicas corriendo y usuarios reales conectados en el momento exacto del despliegue. Esta lección te nombra las tres estrategias estándar que resuelven ese problema —blue/green, canary, rolling— con su sintaxis real, sin construir ninguna.

Conexión con el módulo

Esta lección marca el punto donde el módulo se aleja más del terreno que ya conoces. Las lecciones 2 a 4 compararon herramientas y mecanismos que, de una forma u otra, seguían resolviendo el mismo problema de fondo (aplicar un cambio de infraestructura declarada). Esta lección entra a un problema que no existe en el pipeline de Andes Cargo, porque terraform apply no despliega "réplicas" de nada — aplica un estado nuevo, completo, de una vez. La lección 6 sistematiza esta diferencia con una tabla de contraste explícita entre CI/CD de aplicación y de infraestructura; esta lección es la pieza concreta que esa tabla necesita para no quedarse en abstracto.

Por qué esta guía nunca tuvo este problema

Pensalo con un ejemplo concreto de esta guía. Cuando el Módulo 3 agregó el tag Compliance al bucket andes-cargo-shipment-docs, terraform apply no dejó "dos buckets" corriendo mientras alguien decidía cuál usar — modificó el bucket existente, in situ, de una sola vez. Lo mismo pasa con la tabla Shipments, con los roles IAM, con la función Lambda: cada uno de esos recursos tiene un estado en un momento dado, y apply lo mueve de un estado al siguiente, sin una fase intermedia donde ambas versiones coexisten sirviendo tráfico real.

Una aplicación con réplicas corriendo es distinta. Imagina que process-shipment-manifest (la función Lambda de Andes Cargo) fuera, en cambio, una API corriendo en tres contenedores detrás de un balanceador de carga, recibiendo pedidos de usuarios reales en este momento. Si reemplazas el código de los tres contenedores de golpe, hay un instante —por más corto que sea— donde ningún contenedor puede responder pedidos: eso es downtime. Si el código nuevo tiene un bug que no viste en pruebas, todos los usuarios lo sufren al mismo tiempo, porque no hay ninguna versión anterior corriendo en paralelo para comparar o para volver atrás rápido. Las tres estrategias de esta lección son, cada una, una respuesta distinta a este problema exacto.

Analogía: dos escenarios de teatro

Imagina un teatro con dos escenarios idénticos, uno al lado del otro, pero solo uno iluminado a la vez — el público mira siempre el escenario que tiene las luces encendidas. Mientras el público ve la obra en el Escenario A (iluminado), el elenco puede ensayar la versión nueva de la obra, con cambios, en el Escenario B (a oscuras, sin público mirando). Cuando la versión nueva está lista y probada en B, el técnico de luces simplemente apaga A y enciende B — el cambio de "qué ve el público" es instantáneo, sin ningún momento de escenario vacío entre medio. Si algo sale mal en la nueva versión, la solución es igual de instantánea: apagar B, volver a encender A, la obra vieja sigue exactamente donde estaba, porque nunca se desarmó.

Eso es, con precisión, blue/green: dos entornos completos ("azul" y "verde", los colores son solo una convención de nombres, sin significado técnico especial) corriendo en paralelo, uno sirviendo tráfico real ("iluminado") y el otro listo pero inactivo. El "cambio de luces" es, técnicamente, redirigir el tráfico —de un balanceador de carga, de un DNS, de un enrutador— del entorno viejo al nuevo, de una sola vez.

Las tres estrategias, con precisión técnica

Rolling deployment (reemplazo gradual)

Es la estrategia por defecto de Kubernetes para un Deployment: en vez de reemplazar todas las réplicas de golpe, las reemplaza de a poco, una porción por vez, mientras la versión vieja y la nueva coexisten brevemente durante la transición.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

maxSurge controla cuántas réplicas extra (por encima de la cantidad deseada) Kubernetes puede crear temporalmente para acelerar el reemplazo; maxUnavailable controla cuántas réplicas puede tener fuera de servicio al mismo tiempo durante la transición. Ambos aceptan un número absoluto o un porcentaje. Es la estrategia más simple de las tres —no requiere infraestructura extra, ya viene incluida en el controlador de Deployment de Kubernetes por defecto—, pero también la más limitada: durante la transición, hay usuarios reales siendo atendidos por la versión vieja y usuarios reales siendo atendidos por la versión nueva, al mismo tiempo, sin ningún control fino sobre cuáles.

Blue/green (dos entornos completos, cambio instantáneo)

Según documentación de AWS: "the blue/green deployment strategy is a type of immutable deployment which also requires creation of another environment. Once the new environment is up and passed all tests, traffic is shifted to this new deployment" — el entorno viejo ("blue") se mantiene inactivo, no se destruye, específicamente para poder volver atrás de inmediato (Switch back to old environment es, literalmente, el proceso de rollback documentado para esta estrategia) si algo sale mal.

La diferencia clave contra rolling: en ningún momento hay una mezcla parcial de tráfico entre las dos versiones — es viejo o nuevo, nunca "70% viejo, 30% nuevo" al mismo tiempo. El costo es real: mientras ambos entornos existen, estás pagando por el doble de infraestructura corriendo — el mismo tipo de decisión de costo que ya viste con LocalStack, ahora en un contexto de aplicación, no de laboratorio.

Canary deployment (una porción pequeña, primero)

El nombre viene de una práctica minera real, de mucho antes de la computación: los mineros llevaban un canario en una jaula a las galerías subterráneas porque el ave, al ser más sensible a gases tóxicos que un humano, mostraba síntomas —o moría— antes de que el gas fuera peligroso para las personas, dando una alerta temprana. Un despliegue canary aplica la misma lógica: la versión nueva se envía primero a una porción muy pequeña de tráfico real (5%, 1%, a veces menos), mientras la inmensa mayoría de los usuarios sigue en la versión estable. Si las métricas de esa porción pequeña se mantienen sanas —tasa de error, latencia—, el porcentaje se incrementa gradualmente hasta el 100%. Si algo se degrada, se revierte esa porción pequeña antes de que el problema afecte a la mayoría de los usuarios.

Kubernetes puro no incluye canary como estrategia nativa de Deployment —a diferencia de rolling, que sí viene por defecto—; en la práctica se implementa con herramientas adicionales, como Argo Rollouts (del mismo proyecto CNCF que ArgoCD, lección 3 de este módulo), que según su propia documentación "provide[s] advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes" — la misma familia de herramientas GitOps que ya nombraste, extendida para resolver también este problema. Un ejemplo simplificado, nombrado, no ejecutado:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: andes-cargo-shipment-api
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 10m }
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 100

setWeight: 5 manda el 5% del tráfico real a la versión nueva; pause: { duration: 10m } detiene el avance automático durante diez minutos —tiempo para que un sistema de monitoreo (fuera del alcance de esta guía, territorio de sre-and-incident-response-guide) confirme que las métricas siguen sanas antes de seguir subiendo el porcentaje.

Las tres, por contraste directo

	Rolling	Blue/green	Canary
¿Cuántos entornos completos?	Uno, en transición gradual	Dos, completos, en paralelo	Uno, con una porción de tráfico separada
¿Mezcla de tráfico entre versiones?	Sí, sin control fino	No — nunca mezcla, es un cambio instantáneo	Sí, con control fino y gradual (`setWeight`)
Velocidad de rollback	Media (hay que revertir la transición en curso)	Instantánea (volver a apuntar al entorno viejo)	Rápida (bajar el `setWeight` al 0% de la porción nueva)
Costo de infraestructura extra	Bajo (`maxSurge` temporal)	Alto (doble entorno mientras dura)	Bajo-medio (solo la porción pequeña extra)
Soporte nativo en Kubernetes	Sí (`Deployment` por defecto)	No — requiere herramienta adicional (Argo Rollouts, Flagger u otras)	No — requiere herramienta adicional

Ninguna estrategia "gana" en abstracto — la elección depende de cuánto downtime es tolerable, cuánto presupuesto extra hay para infraestructura duplicada, y cuánto control fino sobre el tráfico necesita el equipo. Un equipo con un presupuesto ajustado y cambios de bajo riesgo puede vivir bien con rolling; un equipo que despliega un cambio de alto riesgo a una API crítica probablemente prefiera canary, aceptando la complejidad extra a cambio de detectar un problema con el 5% de sus usuarios, no con el 100%.

La frontera de esta lección, con precisión

Nada de lo de arriba corrió en esta guía — no hay Deployment de Kubernetes, no hay Argo Rollouts instalado, no hay balanceador de carga con dos entornos configurados. Es, deliberadamente, sintaxis nombrada y verificada contra documentación oficial, no un laboratorio ejecutado. Dos guías del ecosistema cubren esto en profundidad, cada una con su ángulo:

kubernetes-and-eks-in-production-guide — donde estas tres estrategias se implementan de verdad, con un clúster real (o local), probablemente junto con ArgoCD/Flux de la lección anterior, formando el panorama completo de GitOps pull-based + despliegue de aplicación que esta guía solo nombra.
aws-serverless-and-containers-guide — donde el equivalente de blue/green y canary se implementa con herramientas nativas de AWS fuera de Kubernetes: alias de Lambda con desplazamiento de tráfico ponderado, o despliegues de ECS/Fargate con CodeDeploy, resolviendo el mismo problema con un stack completamente distinto.

Errores comunes

Confundir "estrategia de despliegue de aplicación" con "estrategia de rollback de infraestructura" (el más importante, cruza con el Módulo 6). Qué pasa: alguien, recordando el git revert del Módulo 6 (rollback de infraestructura), asume que blue/green o canary son formas alternativas de hacer lo mismo, solo que "más avanzadas". Por qué pasa: ambos usan la palabra "rollback" en algún momento de su explicación. Cómo detectarlo: si piensas que podrías reemplazar git revert + apply.yml con "usar blue/green" para el HCL de Andes Cargo. Cómo corregirlo: son dos problemas de capas distintas. El rollback del Módulo 6 revierte un commit de HCL declarativo — no hay "dos versiones de infraestructura corriendo en paralelo" en ningún momento, el revert simplemente calcula un plan nuevo. Blue/green resuelve, en cambio, cómo pasar tráfico real entre dos versiones de un artefacto de aplicación corriendo simultáneamente — un problema que solo existe cuando hay réplicas activas sirviendo usuarios, algo que Terraform, en esta guía, nunca tuvo.

Creer que Kubernetes "incluye" blue/green y canary igual que rolling (de expectativa técnica). Qué pasa: alguien, viendo que Deployment tiene strategy: RollingUpdate nativo, asume que cambiar a strategy: BlueGreen sería igual de directo. Por qué pasa: las tres estrategias se presentan juntas en esta lección, como si tuvieran el mismo nivel de soporte. Cómo detectarlo: si buscas un campo strategy: type: BlueGreen en la documentación de Deployment de Kubernetes y no lo encuentras. Cómo corregirlo: Kubernetes puro (el recurso nativo Deployment) solo incluye rolling — blue/green y canary requieren un controlador adicional, como Argo Rollouts (que reemplaza Deployment por su propio recurso Rollout, el que viste arriba) o Flagger, otra herramienta con el mismo propósito. No es una limitación menor: es la razón por la que estas dos estrategias tienen su propio ecosistema de herramientas, en vez de ser un simple cambio de configuración.

Pensar que canary siempre es "mejor" que blue/green por ser más gradual (de juicio de valor). Qué pasa: alguien concluye que canary es, en general, la estrategia superior porque reduce el riesgo de forma más fina que un cambio instantáneo. Por qué pasa: "gradual y con control fino" suena, intuitivamente, más seguro que "todo o nada". Cómo detectarlo: si tu conclusión de esta lección es "siempre usar canary". Cómo corregirlo: canary tiene un costo real que blue/green no tiene — requiere tiempo (los pause: duration entre pasos) y un sistema de monitoreo confiable para decidir automáticamente si el setWeight avanza o se revierte. Para un cambio de bajísimo riesgo, ese costo puede no valer la pena frente a la simplicidad de blue/green o incluso rolling. La elección correcta depende del riesgo real del cambio, no de una jerarquía fija entre las tres.

Ejercicios

Ejercicio 1 — Explica por qué esta guía nunca tuvo este problema. Sin mirar esta lección, explica en dos o tres frases por qué terraform apply sobre andes-cargo-infra/ nunca necesitó una estrategia de blue/green, canary o rolling.

Ver solución

Una explicación completa suena, más o menos, así: "Estas tres estrategias resuelven cómo pasar tráfico de usuarios reales entre dos versiones de una aplicación que están corriendo simultáneamente durante la transición. terraform apply no tiene ese problema porque no despliega réplicas de una aplicación — modifica el estado de recursos declarados (un bucket, una tabla, un rol IAM) de una sola vez, sin una fase intermedia donde 'la versión vieja del bucket' y 'la versión nueva del bucket' coexisten sirviendo tráfico en paralelo. El problema que estas tres estrategias resuelven simplemente no existe en el modelo de Terraform tal como esta guía lo usó."

Ejercicio 2 — Elige la estrategia correcta para tres escenarios. Para cada escenario, elige rolling, blue/green o canary, y justifica en una frase: (a) un cambio de configuración de bajísimo riesgo en un servicio interno sin usuarios externos; (b) un cambio grande al sistema de pagos de una aplicación crítica, con presupuesto para infraestructura duplicada; (c) un cambio experimental de un algoritmo de recomendaciones, donde el equipo quiere medir el impacto en un grupo pequeño antes de decidir.

Ver solución

(a) Rolling — el riesgo es bajo, no justifica el costo extra de un segundo entorno completo ni la complejidad de monitoreo gradual de canary; el reemplazo gradual por defecto es suficiente. (b) Blue/green — un sistema de pagos crítico se beneficia del rollback instantáneo (volver a apuntar al entorno viejo, sin ninguna mezcla de tráfico durante la transición) más que de cualquier otra propiedad, y el escenario ya asume presupuesto disponible para el doble de infraestructura. (c) Canary — el objetivo explícito es medir el impacto en un grupo pequeño antes de decidir, que es exactamente lo que setWeight con pasos incrementales está diseñado para hacer; ni rolling ni blue/green ofrecen ese control fino de "cuánto tráfico ve la versión nueva, mientras mido".

Ejercicio 3 — Ubica el nombre técnico de una herramienta. ¿Qué herramienta, nombrada en esta lección, extiende las capacidades de GitOps de ArgoCD específicamente para soportar blue/green y canary en Kubernetes? ¿Por qué tiene sentido que exista en la misma familia de proyectos que ArgoCD?

Ver solución

Argo Rollouts — un controlador que reemplaza el Deployment nativo de Kubernetes por su propio recurso Rollout, con soporte explícito para blue/green, canary, análisis automática de métricas y despliegue progresivo. Tiene sentido que viva en la misma familia de proyectos que ArgoCD (ambos bajo el paraguas "Argo" del CNCF) porque resuelven problemas complementarios del mismo dominio: ArgoCD sincroniza qué manifiestos deberían existir en el clúster según Git (GitOps pull-based, lección 3-4 de este módulo); Argo Rollouts controla cómo se hace la transición cuando esos manifiestos cambian una versión de aplicación por otra (esta lección). Es común usarlos juntos: ArgoCD detecta el cambio en Git, y Argo Rollouts ejecuta la transición gradual en vez de un reemplazo directo.

Resumen y siguiente paso

En esta lección conociste, con sintaxis verificada y sin construir nada, las tres estrategias estándar de despliegue de aplicación: rolling (reemplazo gradual, nativo de Kubernetes), blue/green (dos entornos completos, cambio instantáneo de tráfico), y canary (una porción pequeña de tráfico primero, con incrementos graduales medidos). Entendiste por qué ninguna de las tres fue necesaria en esta guía —terraform apply no despliega réplicas de una aplicación con tráfico real en tránsito— y viste dónde se implementan de verdad: kubernetes-and-eks-in-production-guide para el mundo Kubernetes, aws-serverless-and-containers-guide para el mundo serverless/contenedores nativo de AWS.

Antes de avanzar deberías poder: explicar la diferencia central entre las tres estrategias (mezcla de tráfico, velocidad de rollback, costo); elegir la estrategia correcta para un escenario dado con justificación técnica; y explicar por qué el pipeline de Andes Cargo nunca necesitó ninguna de las tres.

La lección 6 toma un paso atrás y sistematiza, en una tabla corta y explícita, la frontera completa entre CI/CD de infraestructura (lo que construiste) y CI/CD de código de aplicación (lo que esta lección y la anterior empezaron a mostrar) — el contraste que la lección 7 hace tangible con un pipeline real, ejecutado.

Recursos

Kubernetes Docs — Deployments, Rolling Update strategy — documentación oficial de RollingUpdate, maxSurge y maxUnavailable, usada en esta lección.
Argo Rollouts — Documentation — documentación oficial de la herramienta que extiende Kubernetes con blue/green y canary, fuente del YAML de Rollout de esta lección.
AWS Whitepaper — Practicing Continuous Integration and Continuous Delivery on AWS, Deployment methods — fuente de la definición de blue/green citada textualmente en esta lección.
kubernetes-and-eks-in-production-guide (NIEVA) — donde estas tres estrategias se implementan de verdad, junto con ArgoCD/Flux.
aws-serverless-and-containers-guide (NIEVA) — el equivalente de estas estrategias con herramientas nativas de AWS (alias de Lambda, CodeDeploy) fuera de Kubernetes.

← Anterior4. *Push-based* vs. *pull-based*: dos GitOps, un principio Siguiente →6. CI/CD de código de aplicación vs. infraestructura