What is vendor lock-in?

Vendor lock-in refers to a situation where an organization becomes overly dependent on a specific vendor's products or services, making switching to alternatives costly, time-consuming, or technically difficult. Over the years, many companies have experienced frustration when trying to move away from large vendors like IBM, Microsoft, or Oracle due to contractual constraints, proprietary technologies, and sudden pricing changes. A recent example is VMware's acquisition by Broadcom, followed by significant pricing changes that disrupted many businesses.

Some examples?

In startup environments, it's common to hear voices urging multi-cloud strategies or insisting on only using "cloud-agnostic" tools to avoid a potential lock-in that might never materialize. Some even advocate picking tools that must remain relevant for the next 10–20 years—a nearly impossible task. 🙃

Here are some example you too might have heard:

Self-managed Kubernetes

Some teams insist on managing their own Kubernetes clusters because:

1. "Big companies use Kubernetes", so we should too.
2. It's open-source.
3. We should be cloud-agnostic and avoid vendor lock-in at all costs.
4. Se-managed appears to be cheaper than using a managed alternative.

While these reasons seem valid on the surface, managing Kubernetes introduces significant operational complexity. Cloud providers offer fully managed services like Amazon EKS, Google GKE, Azure AKS, or even serverless options like AWS Fargate, which significantly reduce this burden. But still, some prefer self-hosting just to avoid a perceived lock-in. 🫠

Let's build our "own" datacenter!

Although less common today, some businesses still believe running on-premises is more cost-effective and provides more control. Reasons typically include:

1. Public cloud is too expensive compared to owning hardware.
2. "Once you're in the cloud, you're stuck."
3. Physically owning the infrastructure seems safer.
4. Fear of cloud providers "stealing" their ideas. 😂

Recently, influencers like David Heinemeier promote the idea of "let's build our own datacenters" by focusing only on hardware costs. But building and maintaining a datacenter requires considering total cost of ownership (TCO), which includes staffing, the knowledge that is not common anymore, upgrades, security, including physical security, availability, and much more.

We should only use open-source!

Open-source software has been a major driver of innovation and collaboration. It enables transparency, reusability, and often better security insights. However, an overcommitment to open-source can sometimes prevent teams from using excellent managed solutions just because they're proprietary. I'm a big fan of OSS, so don't get me wrong. For example, preferring PostgreSQL or MySQL over managed solutions like Amazon RDS or Google Cloud SQL might lead to higher operational overhead, especially for teams without strong DevOps support.

Why this approach is dangerous?

Making strategic tech decisions based solely on the fear of vendor lock-in often leads to unnecessary complexity. Imagine building software without any libraries or frameworks because they're "opinionated." That logic, if taken to the extreme, leads to teams reinventing the wheel while convincing themselves their startup is building something truly unique. Some leaders boast about being "cloud-portable" and ready to switch providers overnight. In theory, that sounds great. In practice, it's a costly abstraction.

All decisions in engineering are trade-offs:

Should you master multiple programming languages to be vendor-agnostic or pick one that fits your use case well?

Is it practical to use a universal ORM for every database engine or choose one tailored to your stack?

Does it make sense to pay cloud providers for managing repetitive operational tasks?

Is simplicity more valuable than the power of customization and flexibility?

Do you really need every advanced feature of a tool or only a reliable subset?

Is it wise to invest team time in debugging and maintaining infrastructure?

Vendor lock-in only in choosing the public cloud provider?

Vendor lock-in isn't limited to cloud providers. The moment you select a programming language, framework, database, or third-party service, you are accepting a level of dependency. The more deeply you integrate a technology, the harder it becomes to replace.

You may find yourself locked into:

– A specific programming language.

– A database with custom schemas and stored procedures. (DB? logic? Hmm...)

– Custom internal platforms built by someone who left last year. OOPS! We have no documentation either.

– Third-party services for billing, auth, or analytics.

Cloud providers are just one among many dependencies. The key is to choose wisely and be deliberate—not paralyzed by hypothetical future migrations.

What should I do then?

Aim for pragmatic simplicity. Embrace managed services where they make sense, and minimize complexity where possible. The real danger isn’t vendor lock-in—it's complexity lock-in.

Combining too many tools or customizing every layer of your stack increases system entropy. Over time, the culture of "don’t touch it, it works" takes hold. Eventually, systems become so convoluted that nobody understands them—let alone migrates them.

Stay flexible, stay curious—but don’t fear lock-in so much that you lock yourself into choosing over-engineering complexity (when it is not needed yet) or indecision.