Lock-In in the Age of Cloud and Open Source

We love to debate about lock-in. What is vendor lock-in? Are there other types of lock-in? Can the cloud protect you from lock-in? Can an open source solution create lock-in?

The answer is a standard one: It depends.

Every technology choice is a zero-sum game. Resources spent learning and deploying one technology, tautologically, cannot be used for a different one. But lock-in is different.

Customers love to talk about lock-in. Since customers love to talk about it, so do vendors. All right, let’s split some hairs over vendor lock-in!

In the Beginning

Historically, all technology was proprietary, so a technology choice was a vendor choice and vendor choice was a technology choice. They were one and the same. You had two choices, build the technology yourself or buy it from a vendor for a license cost.

Once you incurred the licensing cost, you had a risk that the technology might not even work correctly. If you wanted to change to a different technology, you could, but you had to pay the cost of a new license from the new vendor as well as the cost of adopting the new technology. Adopting a new technology had three component costs: license costs (CapEx), adoption costs (CapEx) and maintenance costs (OpEx).

With most proprietary software, once a user purchases a license, they can continue to use it in perpetuity, as long as they can live with a lack of security updates, etc.

But some proprietary licenses are much more draconian. With the most restrictive proprietary software, there is no mechanism to continue using it without a license, no matter how angry a buyer becomes with a vendor.

There are cases where a user of proprietary technology must pay for a license to use it, every single year. Period. We’ll revisit this subject when we discuss cloud services later.

👁 Image

These costs led to extremely conservative behaviors from buyers. Before buying a software license, a customer really wanted to make sure the software worked as claimed. Any mistake in technology choice or vendor choice could be extremely expensive, so buyers verified potential purchases using white papers, consulting written customer references, speaking with other buyers, consulting with analysts like Gartner or IDC and reading 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 buyers would commit to purchasing a piece of software.

Since the upfront costs of licenses as well as technology adoption were more expensive than maintenance, there was a natural bias to use the same technology stack for a very long time and resist change.

The Open Source Way of Life 

With the advent of open source software, 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.

👁 Image

With open source software, a vendor can’t lock a buyer in. The buyer reserves the right to choose a different vendor at any given time. Even when there’s only a single vendor who sells support for a particular piece of open source code, the buyer still has options. The buyer can lure another vendor to support it, support it themselves, pay a consultant to support it or even run it unsupported. The original vendor has no ability to force the buyer to continue a financial relationship. This is game-changing from a vendor lock-in perspective.

Effectively, open source disconnects the technology choice and the vendor choice. Which technology you adopt and who you choose to adopt it from can be two completely different choices. Moreover, these choices have distinctly different risks and rewards.

The Fastest Way to Adoption 

It seems that in recent times, people have forgotten the history of vendor lock-in. They don’t remember how all this started, so there’s a perception that almost anything annoying about technology adoption is lock-in. It’s not.

There are still 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 a technology choice has even more gravity. But gravity doesn’t prevent you from backing out of a decision when you make a mistake. Adoption cost isn’t lock-in per se.

For example, say you make a technology decision to use an open source project to solve a data storage problem. Halfway into the project, you realize the technology won’t scale for your needs, so you have to go find an alternative open source technology, 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 a single vendor that can provide the technology solution that you’ve adopted. Vendor lock-in is when you want to keep the technology but get rid of the vendor. Vendor lock-in is when you can’t even use the technology next year if you don’t pay a new license cost or maintenance cost.

Even in 2021, there are times when a buyer cannot avoid vendor lock-in. Sometimes a proprietary solution really is the only viable solution to a problem, and in those situations, vendor lock-in is necessary. But, in those situations, I recommend using all the processes invented to deal with that: RFPs, analysts, customer references, etc.

Open source has changed IT infrastructure and the web, but in many industries like manufacturing, vendor lock-in is still the default relationship between vendors and buyers.

Going to the Cloud Should Solve Everything 

Kinda yes, kinda no. The cloud can be thought of in three layers: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). While IaaS can be thought of as renting hardware in the cloud, PaaS and SaaS need to be thought of in a completely different way (Hardware 1.0 vs. Hardware 2.0). Migrating between services for IaaS is relatively straightforward, and a buyer is fairly well protected from vendor lock-in. Services higher up the stack, not so much. It remains to be seen if the cloud providers will actually win in the software world, but they are definitely climbing up the stack, just like the original hardware vendors did, because they want to provide stickier solutions to their customers. Let’s explore the difference between these lower-level and higher-level services from a vendor lock-in perspective.

With what I call Hardware 2.0, servers, network and storage are rented in the cloud and provisioned through APIs. The switching costs of migrating virtual machines from one cloud provider equate to learning a new API for provisioning. Tools like Ansible and Terraform reduce these costs even further by giving a buyer a single API to translate across the underlying APIs at each cloud provider. If architected well, a buyer can move between cloud providers with a few config file changes (though storage still has gravity).

👁 Image

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

But services are different. Cloud services like Amazon Kinesis, DynamoDB, ElastiCache, Simple Queue Services, TimeStream, Lambda and even things like Azure DevOps Pipelines, GitHub Actions and AWS Image Builder are completely different than renting a virtual machine.

These services, and especially the often-complex combinations of these services commonly needed to deploy even a single application are only available from one vendor. Worse, cloud services are similar to the most draconian of proprietary licenses. You literally can’t even use them without paying the cloud provider. Deploy with complex combinations of higher-level proprietary services, and voila, we’ve just coupled our vendor choice and technology choice at the hip. There’s even a refactor cost that’s similar to the license costs of proprietary software like the days of yore.

👁 Image

Together, this complex set of services amounts to classic vendor lock-in. I encourage you to lawyer up, consult analysts and really do your homework with other customers if you want to inherently link your technology choices and vendor choices like this.

The Thing about Licensing Is …

This philosophical debate is playing out in public with feuds between vendors like AWS and Redis. This video pits the full-stack solutions of AWS against the full stack solution of Redis, but Redis has one key difference. Even though Redis has made license changes, the license still in use protects buyers. If you get mad at Redis, you can run it yourself or pay a consultancy to run it for you.

Another easily missed detail is the fact that with Redis, buyers still retain the freedom to build a best-of-breed solution. They can decide to buy a server from Dell, an operating system from Red Hat and a data solution from Redis. Or, if they get mad at Dell, Red Hat and Redis Labs, they can rent a virtual machine from Google, use SUSE Linux and pay a consultancy to manage the Redis layer. Or, if they don’t like that, they can use VMware on premises, use Ubuntu Server and hire programmers to maintain Redis for 50 years. You get the point.

👁 Image

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

The Paradox of Choice

Bad technology choices and vendor lock-in are two distinct risks that anybody adopting technology needs to learn about, but they are not the same thing. Bad technology choices are a risk on the way in the door, vendor lock-in is a risk on the way out the door.

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 a core competency — fail fast. You will survive these bad choices, learn from them and become better at making new choices. That’s a strategic investment in the core competencies necessary to be a software-driven company.

Bad vendor lock-in choices are not a strategic investment. Since the vast majority of innovation is coming from open source, there’s little risk or reward for adopting technologies that lock you in to a single vendor. I’ll fight for your right to make as many bad decisions as you want, but I’ll beg that you make them strategically, with a goal in mind!

Come talk to me on Twitter: @fatherlinux