Cloud vendor lock-in: how to make a conscious decision
When vendor lock-in in the cloud is a reasonable trade-off, and when it is a risk worth assessing upfront.
When companies move to the cloud, the vendor lock-in conversation usually comes up in one of two extreme forms. The first: "we must avoid any vendor dependency and use only open standards". The second: "don't think about it at all, use whatever is convenient".
Both positions oversimplify the real picture. The question is not whether dependency will arise - it will, with any choice. The question is what kind of dependency, how manageable it is, and what it would take to exit if that ever became necessary.
Types of lock-in
Not all kinds of lock-in carry the same exit cost.
Data dependency - your data is stored in a proprietary format or with limited export options. This is usually the most painful type of lock-in. Data is a long-term asset, and finding yourself in a situation where it is difficult to move is unpleasant.
Service dependency - you use vendor-specific services: queues, databases, machine learning tools. This creates dependency on the API and behaviour of a specific cloud. Switching will require rewriting integrations.
Operational knowledge dependency - the team knows how to work with a specific vendor's tools: its CLI, console, monitoring instruments. This is people's knowledge, which needs updating during any migration.
Pricing dependency - where switching is technically possible but economically unattractive due to data volume, accumulated discounts, or exit penalties.
When to accept dependency consciously
Using the native services of a cloud vendor is often the right choice. They are well integrated with each other, have a managed operational model, and are backed by engineering teams that monitor reliability.
Building additional abstractions for the sake of "independence" creates its own costs: more code to maintain, potentially lower performance, and often an illusion of independence while actually depending on your own abstraction layer.
Conscious lock-in is fine. Unconscious lock-in is a risk.
What to look at when choosing
A few questions that help form a position:
- Where is our critical data stored - in standard formats or proprietary ones?
- If we need to switch vendors in three years, what will that cost in money and time?
- Do we have strategic reasons to avoid a specific vendor - regulatory, geopolitical, or competitive?
- Are we using vendor-specific services in places where good portable alternatives exist?
- How does the cloud contract govern the right to export data and the terms of service termination?
This is not a call to fear the cloud or to build multi-cloud architecture on principle. It is a call to understand what you are agreeing to.