Deployments Canary en Go: despliegue seguro sin miedo

Deployments Canary con Go: cómo lanzar actualizaciones sin miedo ni riesgo

Imagine: ha pasado años construyendo la arquitectura, escribiendo pruebas, configurando la monitorización. Y entonces — el lanzamiento. Un clic, y la nueva versión vuela a producción. El corazón late con fuerza, los dedos tiemblan. ¿Le suena familiar? ¿Y si le digo que puede desplegar la nueva versión solo al 5% de los usuarios, observar las métricas, y solo entonces implementarla para todos? Sin tiempos de inactividad, sin pánico, con control total.

Esto se llama canary deployment (despliegue canario). El nombre proviene de los mineros que llevaban canarios consigo — el pájaro moría por el gas antes que las personas, advirtiendo del peligro. En el mundo DevOps, esos "canarios" son el primer 5-10% de usuarios que reciben la nueva versión. Si algo sale mal — retrocedemos, sin que se note el problema.

En este artículo, analizaremos cómo implementar un despliegue canary en Go con ejemplos de código reales, un balanceador y métricas. ¡Allá vamos!

¿Por qué Go para el despliegue canary?

Go es un lenguaje creado para microservicios. Se compila en un binario estático, no requiere dependencias en el servidor y se escala fácilmente. Pero lo principal es que Go tiene soporte incorporado para concurrencia y excelentes bibliotecas para servidores HTTP, lo que lo convierte en un candidato ideal para implementar enrutamiento inteligente de tráfico.

• Rendimiento — un servidor Go procesa miles de solicitudes por segundo en un solo núcleo.
• Simplicidad de despliegue — un solo binario, sin máquinas virtuales ni intérpretes.
• Ecosistema rico — paquetes para métricas (Prometheus), trazado (OpenTelemetry) y balanceo.

Si ya escribe en Go y quiere automatizar el despliegue — la estrategia canary será su mejor amiga.

Arquitectura del despliegue canary en Go

Imaginemos que tenemos un microservicio en Go que procesa las solicitudes de los usuarios. Normalmente, desplegamos la nueva versión en todas las instancias a la vez. Con el enfoque canary, ejecutamos la nueva versión en paralelo con la anterior, pero dirigimos solo una parte del tráfico hacia ella.

Aquí hay un esquema simplificado:

1. Versión estable (v1) — funciona en el 90% de las instancias.
2. Versión canary (v2) — ejecutada en el 10% de las instancias.
3. Balanceador — distribuye el tráfico proporcionalmente.
4. Monitorización — compara métricas (latencia, errores, rendimiento).
5. Decisión manual o automática — implementamos v2 al 100% o retrocedemos.

Esto se puede implementar de diferentes maneras: a través de Kubernetes (Service Mesh), a través de Nginx con pesos personalizados, o escribiendo nuestro propio balanceador en Go. Tomaremos el tercer camino: ofrece control total y es excelente para aprender.

Escribiendo un balanceador de tráfico canary en Go

Escribamos un proxy inverso simple que dirija las solicitudes a dos backends: stable y canary. El peso de la versión canary se definirá a través de un archivo de configuración o una variable de entorno.

package main

import (    "log"    "math/rand"    "net/http"    "net/http/httputil"    "net/url"    "os"    "strconv")

type CanaryProxy struct {    stable       *httputil.ReverseProxy    canary       *httputil.ReverseProxy    canaryWeight int // porcentaje de tráfico hacia canary (0-100)}

func NewCanaryProxy(stableURL, canaryURL string, weight int) *CanaryProxy {    stableTarget, _ := url.Parse(stableURL)    canaryTarget, _ := url.Parse(canaryURL)

    return &CanaryProxy{        stable:       httputil.NewSingleHostReverseProxy(stableTarget),        canary:       httputil.NewSingleHostReverseProxy(canaryTarget),        canaryWeight: weight,    }}

func (p *CanaryProxy) ServeHTTP(w http.ResponseWriter, r *http.Request) {    // Tomamos la decisión basándonos en un número aleatorio    if rand.Intn(100) <