The Golden Handcuffs
Vendor lock-in happens when migrating away from a specific vendor — like AWS, Google Cloud, Datadog, or Snowflake — becomes so difficult and expensive that you are effectively stuck with them. Even if they raise prices by 40%, even if their service degrades, even if a better alternative emerges, the switching cost is so high that you stay.
This isn't inherently bad. It's a trade-off. The question is whether you made the choice consciously.
Think of it like buying a house in a city where your employer is the only major employer. The house might be perfect and affordable. But if you ever want to leave that employer, you also have to sell your house and move. That's lock-in. It's not necessarily wrong to buy the house — but you should know what you're signing up for.
The Spectrum of Lock-in:
| Risk Level | Examples | Migration Effort |
|---|---|---|
| Low | Linux VMs, standard PostgreSQL, Docker containers, SSH | Days to weeks |
| Moderate | AWS S3 (many tools support its API), Kubernetes, Terraform | Weeks to months |
| High | AWS Lambda + API Gateway, Google BigQuery, Azure Cosmos DB | Months |
| Very High | AWS DynamoDB with DAX caching, proprietary ML services, vendor-specific workflow engines | Months to years, possibly a full rewrite |
The Trade-off: Proprietary services are often extraordinarily powerful and let you move very fast. AWS DynamoDB gives you single-digit millisecond latency at any scale with zero operational overhead. Building equivalent capability yourself would take months. But your application code, your data model, and your operational knowledge all become tightly coupled to that vendor's unique APIs. The power is real. So is the coupling.
How to assess lock-in risk for any service:
- API Portability: Does the service use a standard protocol (SQL, HTTP REST, S3-compatible API) or a proprietary one? Standard protocols mean other vendors can implement the same interface.
- Data Portability: Can you export your data in a standard format? How large is the dataset, and how long would migration take? A terabyte of data in a proprietary format is a very different problem from a gigabyte in CSV.
- Code Coupling: How deeply is the vendor's SDK embedded in your application code? Is it isolated behind an abstraction layer, or spread throughout every service?
- Operational Knowledge: Has your team built deep expertise in this vendor's tooling? Would switching mean retraining everyone on a new paradigm?
- Contract Terms: Are there minimum commitments, egress fees (charges for moving data out), or contractual penalties for leaving?
When asked about vendor lock-in, don't default to "we should avoid all lock-in." That's naive — it means you'd never use any managed service, which is impractical and would leave enormous productivity on the table. Instead, say: "I assess lock-in risk on a per-service basis. For commodity infrastructure like compute and storage, I prefer portable options. For differentiated capabilities where a proprietary service gives us a significant advantage, I accept the lock-in but isolate it behind an abstraction layer so the blast radius is contained if we ever need to switch." This answer demonstrates nuance and practical experience.
Key Point: The most sophisticated approach to vendor lock-in is not avoidance but containment. Use the adapter pattern or hexagonal architecture to isolate vendor-specific code behind interfaces. If you ever need to switch, you replace the adapter — not the entire application. This costs slightly more upfront but dramatically reduces future switching costs. The decision of where to accept lock-in and where to insist on portability is one of the most consequential architectural choices a team makes — and it should be made explicitly, not by accident.