Cloud
Vendor Lock-in & Multi-Cloud
Every managed service trades portability for velocity: proprietary APIs like DynamoDB and Lambda are the fastest way to ship and the hardest to leave. Multi-cloud as a strategy is usually a tax paid for an exit nobody exercises. The pragmatic middle: open standards at the seams — containers, Postgres, S3-compatible APIs — and accepted lock-in where the payoff is real.
Purpose
Lock-in is the switching cost accumulated by building on things only one vendor offers — proprietary APIs, service-specific data models, egress-priced data gravity. The concept matters not because lock-in is evil but because it is a price, usually invisible at adoption time and enormous at exit time. Thinking about it explicitly turns "we use whatever AWS suggests" into a decision with known costs.
When to Use It
The question appears at every build-vs-managed fork: DynamoDB or Postgres? Lambda or containers? Each proprietary choice buys velocity now and narrows options later. It also shapes negotiation — a credible migration path is leverage at contract renewal — and compliance, where some industries genuinely require an exit plan or multi-region-multi-provider resilience.
Trade-offs
Full multi-cloud — the same workload runnable anywhere — means building to the lowest common denominator, forgoing the managed services that justify the cloud in the first place, and doubling operational surface; few organisations that claim it actually fail over. Total lock-in avoidance is self-harm for a small team. The realistic failure mode is not choosing a side but drifting into deep coupling without noticing.
Implementation
Standardise the seams: containers for compute, Postgres/MySQL for data, S3's API for objects (it is a de-facto standard with many implementations), Terraform for provisioning, OpenTelemetry for observability. Then take lock-in deliberately where the managed service earns it, and record the decision and its exit cost in an ADR. Watch egress fees — data gravity, not APIs, is often the strongest chain.