Vendor Lock-In: What Is Real and What Is Overstated

Lock-in is real, and it is also the most common justification for building
something more complicated than necessary. The useful distinction is between
coupling that would genuinely make leaving hard and coupling that would merely
make it inconvenient.

The forms that genuinely constrain you

Data gravity

The strongest and least discussed. Large volumes of data are slow and
expensive to move, because the source provider bills egress on the way out.
Every terabyte accumulated makes leaving marginally harder, and this happens
without any architectural decision at all.

This is the one to take seriously, and it argues for knowing your egress
terms before accumulating data rather than after. See
data egress fees explained.

Proprietary managed services with no equivalent

Using a provider’s specific data warehouse, event streaming platform or
machine learning service means an equivalent must be found or built elsewhere.
Where a genuine equivalent exists, this is a migration. Where one does not, it
is a redesign.

Operational capability you no longer have

The least visible form. If a managed service has been handling your
replication and failover for three years, moving to something self-operated
means acquiring that capability. The lock-in is in your team’s experience rather
than in your code.

Commercial commitments

Multi-year reserved capacity and committed spend agreements are contractual
lock-in with a precise end date. Entirely rational to enter, provided the term
matches your confidence in the workload still existing.

The forms that are overstated

Compute and block storage

A virtual machine running Linux is a virtual machine running Linux. Moving
one between providers is routine work. If your deployment is servers, disks and
a standard database, you are substantially less locked in than the discourse
suggests.

Object storage

The dominant interface is widely implemented, and most object storage
services are reachable with the same tooling. Moving data costs egress, which is
the data gravity point, but the interface itself is not a barrier.

Managed Kubernetes

Kubernetes is deliberately portable. Workload definitions move between
managed offerings with modest changes, mostly around storage classes, ingress
and identity. Choosing managed Kubernetes specifically to avoid lock-in,
however, is usually the wrong trade: you take on substantial complexity to
preserve portability you may never use.

Standard databases

Managed PostgreSQL or MySQL is ordinary PostgreSQL or MySQL with operations
attached. Moving to another provider’s managed offering, or to a self-hosted
instance, is a well-trodden path. This is quite different from a proprietary
database with no equivalent elsewhere.

What portability actually costs

Avoiding every proprietary service means building the capabilities yourself,
which is slower, more expensive and more likely to be done worse than a
provider’s version. Teams that pursue portability aggressively frequently end up
with a worse system in order to preserve an option they never exercise.

The honest framing is that managed services are a trade, not a trap. You are
buying out of operational work, and buying back in later costs roughly what you
avoided plus the migration. That is often an excellent deal, and it is worth
making knowingly.

The cheap decisions worth making

These preserve most of your optionality at almost no cost:

• Use standard database engines rather than proprietary
  ones, unless the proprietary one solves a problem you actually have.
• Keep the application in containers, which makes where it
  runs a smaller question.
• Keep configuration in environment variables rather than
  baked into platform-specific mechanisms.
• Put an abstraction at the boundary of any proprietary
  service you do use, so the dependency sits in one module rather than throughout
  the codebase.
• Know your data volume and egress terms, so the cost of
  leaving is a number rather than an unknown.
• Keep infrastructure defined in code, which is useful
  immediately and doubles as the documentation a migration needs.

None of these requires avoiding managed services. They just mean the
dependency is deliberate and bounded.

A proportionate way to think about it

Ask what leaving would actually cost: the data transfer, the engineering, the
retraining, the period of reduced effectiveness. If that number is tolerable,
you are not locked in, whatever services you use. If it is not, identify which
specific dependency is responsible and decide whether it is earning its cost.

For most small and medium deployments the answer is reassuring. The
architecture that makes a migration feasible is the same one that makes the
system comprehensible, and it is covered in
planning a migration between cloud
providers.