Cloud vendor lock-in! How much should I be scared of? 😱

Originally written at pooyan.info

Who is the author? Check out my profile on LinkedIn.

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.
   1. "Once you're in the cloud, you're stuck."
   2. Physically owning the infrastructure seems safer.
   3. 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.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

• All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
• All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
• While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
• The contents of this article should not be construed as legal advice.
• Opinions are my own and not the views of my employer.
• English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
• Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
• If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.