How we should think about cloud lock-in

Does the word lock-in send shivers up your spine? Does vendor lock-in keep your CIO or CTO up at night? Is lock-in really costing organizations tons of money in 2022? The short answer is, no.

The early days of technology adoption

Two to three decades ago, all technology you bought was proprietary. A technology choice was a vendor choice, and a vendor choice was a technology choice—they were one and the same. If you didn’t build software yourself (a truly slow and arduous process in those days), you had to buy it from a vendor for a license cost—and hope that it worked the way you expected (and the vendor said) it would work. If the software didn’t work as advertised, you had to (painfully) live with it or start (and pay) all over again.

Not surprisingly, this led to extremely conservative behaviors from buyers. Any technology misstep could be extremely expensive. This was the era of white papers, customer and peer references, consultations with analysts, and dozens of trade magazines. The concept of a request for proposal (RFP) became popular in this era to force vendors to disclose as much information as possible before the software sale. 

Open source changed the world

With the advent of open source software, it became much easier for buyers to change technologies. The lack of a software license cost reduced the friction to change. With open source, you still had a cost to adopt and learn the new technology, but there was another hidden advantage.

With open source software, a vendor can’t lock a buyer in. The buyer has many options. If there is only a single vendor who sells support for a particular piece of open source code, the buyer can still choose to leave that vendor. The buyer can support the sofware themselves, or even pay consultants to support it. 

Effectively, open source disconnected the technology choice and the vendor choice. What technology you adopt, and who you choose to adopt it from are two completely different choices. Moreover, these choices have distinctly different risks and rewards.

Technology adoption vs. vendor lock-in

It seems that, in recent times, people have forgotten the history of vendor lock-in. They don’t remember how all of this started, so there’s a perception that making a decision to use a particular open source technology is lock-in. It’s not.

There are surely adoption costs with open source technology, and that creates gravity, but gravity and lock-in are two distinctly different concepts. Making any choice has gravity. Making technology choices has even more gravity. But, gravity doesn’t prevent you from backing out of a decision when you make a mistake. Cost isn’t lock-in per se.

For example, let’s say you make a technology decision to use an open source project to solve a data storage problem. About halfway into the project, you realize the technology won’t scale for your needs, so you have to go find an alternative open source project, invest time in learning and deploying it, and take yet another risk in adopting this new project. 

That’s not lock-in.

No, my friend, lock-in is a much more insidious thing. Lock-in is when there’s only one vendor on the planet that can provide the technology solution you’ve adopted. Lock-in is when you want to keep the technology, but get rid of the vendor! 

Even in 2022, there are times you have to submit to vendor lock-in. Sometimes a proprietary solution really is the only viable alternative. In industries like manufacturing, for example, vendor lock-in is still par for the course. When this is the case, I recommend using all of the “old-school” vetting processes developed to prevent bad decisions (RFPs, analyst consultations, customer references, etc). 

The cloud is different, right?

You might be thinking that the cloud negates this whole discussion. Well, yes and no. Renting hardware in the cloud, and using cloud services higher up the stack, are two completely different things (Hardware 1.0 vs. Hardware 2.0). Technology adoption costs can differ wildly in different parts of the hardware and software stack. It remains to be seen if the cloud providers will actually win in the software world, but they are trying to climb up the stack just like the original hardware vendors tried to.

With what I call Hardware 2.0, servers are rented in the cloud and provisioned through APIs. The switching costs of migrating virtual machines from one cloud provider to another amount to learning a new API for provisioning. Tools like Ansible and Terraform can reduce these costs even further by giving you a single technology layer across these APIs, thereby almost completely eliminating any vendor lock-in.

This leaves us with costs quite similar to open source software adoption. Sure, there’s an adoption cost, but there are no license fees. The end product that you get from each of the cloud providers is pretty much equivalent in capabilities. There is some differentiation for things like Arm, GPUs, etc., but that’s normal differentiation like hardware vendors have done for years. 

Higher-level cloud services are different. Cloud services like Amazon Kinesis, Amazon DynamoDB, and AWS Lambda, and even tools like Azure DevOps Pipelines and GitHub Actions, are completely different than renting a virtual machine. Since each of these services, and the complex combinations of these services that are needed for a single application to function, are available from only one vendor, we’re back to having an additional cost similar to the license costs in days of yore.

Together, this complex set of services amounts to classic vendor lock-in. I encourage you to lawyer-up, RFP-up, and analyst-up if you want to inherently link your technology choices and vendor choices together like this. 

I wonder if the pendulum is swinging back the other way with the cloud? Or, I wonder if the cloud vendors are going the way of the hardware vendors before them, and will be replaced by open source software start-ups nipping at their heels?

Splitting hairs

Bad technology choices and vendor lock-in are two distinct risks. 

If you are adopting technology quickly, in an attempt to garner reward for taking risk, you will make some bad technology choices. Bad technology choices are par for the course. You will back these technologies out, learn from them, and become better at making new choices. It’s an investment.

Bad vendor choices are not a strategic investment. Since the vast majority of innovation in development paradigms and tools are developed through open source, there’s very little upside in adopting technologies that lock you into a single vendor. 

Personally, I believe you should have the right to make as many bad decisions as you want! Come talk to me @fatherlinux on Twitter!

At Red Hat, Scott McCarty is senior principal product manager for RHEL Server, arguably the largest open source software business in the world. Focus areas include cloud, containers, workload expansion, and automation. Working closely with customers, partners, engineering teams, sales, marketing, other product teams, and even in the community, Scott combines personal experience with customer and partner feedback to enhance and tailor strategic capabilities in Red Hat Enterprise Linux.

Scott is a social media startup veteran, an e-commerce old timer, and a weathered government research technologist, with experience across a variety of companies and organizations, from seven person startups to 12,000 employee technology companies. This has culminated in a unique perspective on open source software development, delivery, and maintenance.

—

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.