Get used to cloud vendor lock-in

I’ll admit I felt a bit vindicated by this article about “embracing the discomfort” with cloud vendor lock-in. This is a reality I’ve stressed for years as organizations move to single and multicloud deployments. My viewpoint is not the result of a bunch of external research, but the realities of seeing lock-in as a fact of many cloud deployments past and present.

Lock-in is a very old problem, by the way. Back in the day, we had numerous 32-bit operating systems on PCs, including many Unix flavors, Windows, and even OS/2. There was a call to build applications that could operate across platforms, which would thus avoid vendor lock-in. As somebody who reviewed development and deployment tools as well as target operating systems, I found myself knee-deep in the lock-in dilemma. 

I noticed right away that those who tried to build software that ran on all platforms using any number of API translation layers and OS emulators usually ended up with software that operated poorly on all platforms. Those who built applications using the native features of the platform had much better, more-responsive software that took less time to build. This fundamental trade-off of avoiding vendor lock-in remains the core issue today. 

Granted, now the game is a bit different with higher stakes. Many cloud providers offer the same operating systems and processor options, the same databases, and even the same ops and security tools. So, why is vendor lock-in still a trade-off?

As an aside, if you just announced that you’re off to build systems that completely avoid vendor lock-in, I will wish you good luck. However, unless you want consistently crappy applications, you’ll have to leverage native security, native infrastructure as code, serverless systems, etc., that are usually supplied by different providers as native services, which is why you’re on a public cloud in the first place.

If we move to the most feature-rich public cloud platforms, it’s to take advantage of their native features. If you use their native features, you lock yourself in to that cloud provider—or even lock yourself in to a subplatform on that cloud provider. Until there are alternatives, you better get used to lock-in. 

I get it. Lock-in means placing major bets on specific technology providers, in this case, the cloud providers. The potential nightmare scenario is that a vendor’s prices might get substantially raised at any time, and budgets are tightly coupled to the pricing whims of the primary public cloud provider. Companies are afraid the public cloud provider might decide to get into their customers’ market (which is happening), or have reliability problems, or get purchased by a competing company, or go bankrupt, or do something else to create problems. 

Obviously, one or more of those things could happen, but for most companies, the risk is extremely low. At the very worst, you would deploy an egress plan that I advise everyone to have anyway. An egress plan outlines other platforms you can move to in the event of a crisis and how you would make that move. Yes, it’s a bit of hassle and money, but it’s often worth the peace of mind. You’ll preemptively mitigate the dangers and have a clearer understanding of the risk of lock-in and how to minimize potential impacts. 

Is lock-in good? No, but it can’t be entirely avoided. Adjust your thinking a bit and understand that it’s all a matter of managing the risks and trade-offs.