OTel Strangler Fig — CultureTech Playbook

El contexto

La mayoría de los equipos que adoptan OpenTelemetry vienen de uno de dos puntos:

1. Logs custom estructurados sobre Loki/Elastic con un schema que se inventó hace 5 años y nadie quiere tocar.
2. APM cerrado (Datadog, New Relic) con vendor lock-in profundo y un contrato anual de seis cifras.

En ambos casos la migración big-bang a OTel es teóricamente correcta pero políticamente imposible. Este playbook documenta el patrón Strangler Fig de Martin Fowler aplicado específicamente a la adopción de OpenTelemetry.

El patrón Strangler Fig

Originalmente descrito en 2004 por Fowler como una estrategia de migración: en lugar de reescribir el sistema viejo, plantar un sistema nuevo alrededor del viejo y dejar que crezca hasta sofocarlo (como la higuera estranguladora real).

Tres fases:

1. Captura paralela — los nuevos datos se capturan en ambos sistemas simultáneamente. El viejo sigue sirviendo de fuente de verdad.
2. Comparación en vivo — los dashboards del sistema nuevo se contrastan contra los del viejo. Cuando hay match consistente, el equipo gana confianza.
3. Switchover progresivo — servicio por servicio, el sistema nuevo pasa a ser fuente de verdad. El viejo queda para query histórica hasta sunset.

Aplicado a OpenTelemetry

Fase 1 — Captura paralela

Para cada servicio en el catálogo, agregar el SDK de OpenTelemetry sin remover el logger viejo. El SDK exporta a un OTel Collector local que encola en Kafka (o equivalente).

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc: {}
      http: {}
exporters:
  kafka:
    brokers: ["kafka-otel:9092"]
    topic: otel-traces-staging
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [kafka]

Costo: el SDK añade ~5-10ms por request en P99 si está bien tuneado, y ~1-2% CPU. Si tu servicio no tolera eso, no es candidato para esta fase y queda para más tarde.

Validación: cada request debe aparecer en ambos sistemas. Si no aparece en OTel, el SDK no está instrumentando ese path — investigar antes de avanzar.

Fase 2 — Comparación en vivo

Replicar los dashboards críticos del sistema viejo en el nuevo (Grafana contra ClickHouse o Tempo, según el destino que elijas). Cada dashboard es una misma pregunta de negocio respondida con dos fuentes.

Métricas a comparar:

• Latencia P50/P95/P99 por endpoint.
• Tasa de error por código.
• Throughput por servicio.

Si una métrica no concuerda en ±5%, hay un problema de instrumentación en OTel. Resolver antes de seguir.

Fase 3 — Switchover progresivo

Por servicio (no por dashboard), declarar OTel como fuente de verdad:

1. Alertas migran a OTel.
2. Runbooks se actualizan para apuntar a los nuevos dashboards.
3. El equipo de oncall confirma que puede operar con la nueva fuente.
4. Solo entonces se desconecta el exportador al sistema viejo.

El sistema viejo queda recibiendo solo el tráfico que aún no migró + query histórica.

Trampas comunes

• Saltar Fase 2. Es la fase más larga y aburrida — exactamente por eso se salta. Cada vez que se ha saltado, el primer incident en el nuevo sistema genera duda institucional y la migración se revierte.
• Migrar dashboards antes de servicios. El dashboard es la salida; el servicio es la fuente. Migrar el dashboard sin tener el servicio instrumentado correctamente da “datos en el nuevo sistema” que no son reales.
• Asumir que otel-collector es plug-and-play. No lo es. La configuración default no funciona para volúmenes serios; se necesita tuning de batching, memory limits y backpressure.

Cuándo NO usar Strangler Fig

• Greenfield. Si el sistema es nuevo, OTel desde el día uno. No hay nada que estrangular.
• Sistemas pequeños (<10 servicios). El overhead organizacional de las tres fases supera el beneficio.

Lectura relacionada

• Martin Fowler, “Strangler Fig Application”, 2004.
• OpenTelemetry, Specification 1.x.

¿Estás migrando?

Si tu equipo está en este momento y necesita guía: Assessment de 30 minutos, gratis, sin pitch comercial.