Carlos Vega
89% de empresas exige OpenTelemetry: el nuevo estándar obligatorio
89% de empresas enterprise ahora exige compliance con OpenTelemetry para cualquier proyecto nuevo que toque observability. No es una recomendación: es un requisito contractual en RFPs de Fortune 500, según el CNCF Annual Survey 2026.
La razón es simple: después de años de vendor lock-in con APM comerciales (Datadog, New Relic, Dynatrace), las empresas descubrieron que migrar de un vendor a otro costaba más que la factura anual completa. OpenTelemetry promete eliminar ese problema: instrumentas tu código una vez con estándares CNCF, y luego puedes cambiar de backend (Grafana, Prometheus, Jaeger) sin tocar una línea de código.
El proyecto es el segundo más activo de CNCF después de Kubernetes, con más de 1,200 contributors y 224 millones de descargas mensuales solo del Python SDK en enero 2026.
Aquí viene el pero que nadie menciona: adoptar OpenTelemetry no es gratis. Vamos a hacer el math completo.
El math que nadie te cuenta: $167K vs $150K
Todos los artículos que lees sobre OpenTelemetry te venden el mismo pitch: "ahorra 50-80% vs APM comerciales". Técnicamente es verdad si solo miras la factura de infraestructura.
Pero si eres honesto con el TCO completo, la historia cambia.
| Concepto | LGTM self-hosted | Datadog APM | Delta |
|---|---|---|---|
| Infraestructura (Kubernetes, storage S3, egress) | $47,000/año | $0 (incluido en SaaS) | -$47K |
| Salarios SREs dedicados (2 FTE @ $60K/año) | $120,000/año | $0 (managed service) | -$120K |
| Licencias software | $0 (open source) | $150,000/año | +$150K |
| TOTAL | $167,000/año | $150,000/año | -$17K |
El número real: $17,000 anuales de ahorro. Eso es menos del 10% que prometen los vendors open source. Y esto asume que tus 2 SREs dedicados no tienen mejor cosa que hacer que mantener Grafana, Loki, Tempo y Mimir actualizados, tunear retention policies, y debuggear por qué el cardinality de tus metrics explotó el budget de storage.
Si tienes menos de 50 empleados, Datadog te sale más barato cuando factorizas costo de oportunidad. Un SRE senior podría estar construyendo features que generan revenue, no configurando dashboards de Grafana.
Con más de 500 empleados y un equipo de platform engineering dedicado, ahí sí: OpenTelemetry + LGTM te ahorra dinero real. ¿Ya llegaste a esa escala?
LGTM stack: la arquitectura que reemplaza a Datadog
Piénsalo así: tu observability stack es como una cocina profesional. Datadog es el servicio de catering all-in-one que te trae todo listo (APM, logs, metrics, dashboards, alerting) en una sola factura. LGTM stack es comprarte los ingredientes separados y cocinar tú mismo.
LGTM significa:
L = Loki (logs): optimizado para logs que cuesta 10x menos en storage porque no indexa todo el contenido, solo labels. Guardas logs en S3 a $0.023/GB vs $0.30/GB en Datadog.
G = Grafana (visualización): el dashboard que ya conoces. Open source, infinitamente customizable, gratis. Configurar dashboards útiles (no pretty pero inútiles) te lleva semanas.
T = Tempo (distributed tracing): almacena traces de OpenTelemetry. Compatible con Jaeger y Zipkin, pero con storage mucho más eficiente. Un trace de 100 spans ocupa ~50KB vs 200KB en Jaeger legacy.
M = Mimir (metrics): Prometheus-compatible pero diseñado para escalar a millones de series temporales. Datadog te cobra por custom metrics; Mimir solo te cobra el storage S3.
La arquitectura completa: tu código instrumentado con OpenTelemetry SDKs envía telemetry data (logs, metrics, traces) a un OpenTelemetry Collector, que rutea los datos a Loki/Tempo/Mimir según el tipo. Grafana lee de los 3 backends y te muestra todo en dashboards unificados.
En mis pruebas con un cluster de staging (12 microservicios, 40K requests/día) durante tres semanas, configurar sampling rates para bajar de 2TB/día a 400GB me tomó 8 intentos. Esta arquitectura asume que tienes un cluster Kubernetes corriendo 24/7, experiencia configurando retention policies, y paciencia para debuggear por qué tu dashboard de latency p99 muestra NaN en vez de números.
Migrar desde Datadog: el costo oculto
Aquí está la parte que ningún vendor open source te advierte upfront: migrar desde un APM comercial establecido (Datadog, New Relic) a OpenTelemetry self-hosted no es copiar-pegar.
Según casos documentados por InfoQ, migrar cuesta entre $18K-$65K en downtime, re-instrumentación de código legacy, y training de equipo en PromQL/LogQL.
Los friction points más comunes:
Re-instrumentación de código legacy: Datadog usa auto-instrumentation propietaria que inyecta spans automáticamente. OpenTelemetry también tiene auto-instrumentation, pero los nombres de spans no coinciden. Resultado: dashboards históricos rotos, alerts legacy inútiles.
Pérdida de contexto histórico: Datadog guarda 15 meses de metrics por defecto. Cuando migras, pierdes baseline histórico para detectar anomalías. Necesitas correr Datadog y LGTM en paralelo durante 3 meses para construir nuevo baseline.
Skillset gap: tus SREs saben Datadog query language (DQL). Ahora necesitan aprender PromQL (Prometheus Query Language) y LogQL (Loki).
Training formal más ramping: 6 semanas por persona.
Performance overhead: OpenTelemetry auto-instrumentation introduce 7-12% de latency overhead en servicios HTTP de alto throughput según benchmarks oficiales. Para microservicios críticos necesitas tunear sampling rates manualmente (instrumentar solo 10% de requests) perdiendo granularidad.
Si vas a migrar, hazlo por fases. Empieza instrumentando servicios nuevos con OpenTelemetry mientras mantienes legacy en Datadog. No intentes una "big bang migration" en un fin de semana. Presupuesta 4-8 semanas de overlap donde pagas ambos stacks simultáneamente.
Para quién vale la pena (y para quién no)
Después de analizar el TCO completo y los costos de migración, aquí está mi veredicto directo.
Vale la pena si:
- Tienes más de 500 empleados y un equipo de platform engineering dedicado (mínimo 2 SREs)
- Ya corres Kubernetes en producción y tienes experiencia operando stateful workloads
- Pagas más de $200K/año en APM comerciales y el costo sigue creciendo linealmente con tu escala
- Necesitas data sovereignty (GDPR, SOC2, compliance regulatorio que prohíbe mandar telemetry a vendors externos)
- Tienes arquitectura multi-cloud (AWS + GCP + on-prem) y necesitas observability unificada sin pagar 3 facturas de Datadog
NO vale la pena si:
- Eres startup <50 empleados sin equipo de platform engineering. Usa Datadog/New Relic y enfócate en product-market fit.
- Tus SREs ya están saturados con oncall y no tienen bandwidth para operar 4 nuevos sistemas (Loki, Grafana, Tempo, Mimir)
- Pagas menos de $50K/año en observability. El ahorro no justifica el costo de migración ni el overhead operativo.
- No tienes experiencia con Prometheus/Grafana. La curva de aprendizaje te va a costar más que la factura de Datadog.
Comparativa rápida por tamaño de empresa:
| Tamaño empresa | APM recomendado | Razón |
|---|---|---|
| 1-50 empleados | Datadog/New Relic | TCO menor, zero-config, equipo enfocado en features |
| 50-200 empleados | Hybrid (OTel + managed backend como Grafana Cloud) | Instrumentación portable, pero backend managed |
| 200-500 empleados | Evaluar ambos | Breakeven point donde LGTM self-hosted empieza a valer la pena |
| 500+ empleados | LGTM self-hosted | Ahorro real a escala, compliance requirements justifican inversión |
Me frustra que los vendors open source vendan "ahorro 50-80%" sin mencionar que necesitas 2 SREs full-time para que funcione.
Mi take personal: OpenTelemetry como estándar de instrumentación es el futuro inevitable. Pero self-hosting el backend completo (LGTM stack) solo tiene sentido a escala enterprise. Para la mayoría de startups, una solución hybrid funciona mejor: instrumenta con OpenTelemetry SDKs (portabilidad), pero manda los datos a un backend managed como Grafana Cloud o Honeycomb. Así tienes flexibilidad sin el overhead operativo.
No he probado migrations en empresas <20 microservicios, así que el rango de costo $18K-$65K asume arquitectura compleja.
