Instrument Once, Route Anywhere

Why this matters

The reason to write OpenTelemetry instead of a vendor SDK is not ideological, it is that instrumentation is the expensive, long-lived asset and backends are the cheap, short-lived one. Instrumenting a large codebase takes months of engineering spread across every team; switching a backend is a procurement decision that happens every few years and, with a vendor SDK, forces you to redo those months. OTLP is the seam that decouples them. Once your services speak OTLP to a Collector, the choice of backend — and the choice to send to two backends during an evaluation, or to split traces and metrics between them — becomes a YAML change in one place. That property is worth more than any individual feature difference between vendors.

Demo

The demo is deliberately anticlimactic: the application does not change at all. What changes is the Collector's exporter list. During a backend evaluation this is how you send production traffic to both candidates at once and compare them on your own data rather than on a sales demo.

Try it yourself

1. Point one service at a Collector instead of directly at your vendor, and confirm the trace still lands with no code change.
2. Add a second exporter to the traces pipeline and verify the same trace appears in both backends with the same trace ID.
3. Split the pipelines: send traces to one destination and metrics to another. Confirm each arrives at only one place.
4. Grep your codebase for vendor SDK imports. Each one is a place a backend change would require a code change — count them.

References

• OpenTelemetry — OTLP specification
• OpenTelemetry Collector — Configuration