Lexicon

Vendor lock-in

Vendor lock-in is the switching cost that keeps you on a platform: agents, formats, query languages, contracts. How observability lock-in works and unwinds.

Definition

Vendor lock-in is the accumulation of switching costs that makes leaving a platform impractical regardless of how the relationship is going: proprietary instrumentation, captive data, workflows that exist in only one tool, and contracts priced to reward staying. In observability, lock-in has historically been severe.

What it means in observability

Observability lock-in earned its reputation honestly. The classic model put a vendor's agent on every host, in every container, sometimes in every function, so switching meant re-instrumenting the entire estate. Years of dashboards, monitors, and runbooks written in a proprietary query language compounded the hold, and the telemetry itself sat in the vendor's cloud, exportable in theory and in practice too large to move. Each renewal negotiation happened with the vendor knowing all of this as well as you did.

How it works in practice

Lock-in operates through three layers. Instrumentation lock: proprietary agents and SDKs that only speak to one backend, which OpenTelemetry was created to dissolve. Data and workflow lock: telemetry stored in proprietary formats behind proprietary query languages, with the accumulated dashboards and alerts as hostages. Commercial lock: multi year commitments and volume discounts engineered so leaving mid contract costs more than staying. Reducing lock-in means addressing each layer, starting with instrumentation, where the open standard now makes portability the default.

Where it gets hard

OpenTelemetry solved less than teams assume. Platforms that are OTel compatible rather than OTel native accept open data at the door and convert it into proprietary shape inside, quietly relocating lock-in from instrumentation to storage. Egress costs make repatriating accumulated telemetry expensive even when export is technically offered. And workflow migration, the dashboards, the alerts, the muscle memory, remains real work that no standard eliminates.

Where Tsuga fits

Tsuga minimizes both ends: OpenTelemetry native means your instrumentation and its exact data shape stay portable, and BYOC means the telemetry sits in your own cloud account either way. If you ever leave, the data was always yours; exit is a configuration change, not a migration project.

Related terms