Cloud lockin: It’s not as bad you might think

Here is a quick guide to deal with the reality of cloud computing lockin, and why it’s a price you usually need to pay

Cloud lockin: It’s not as bad you might think

“I don’t want to get locked in to any specific cloud” is what I hear from clients on a daily basis. Of course you don’t. Who does? 

However, these are the realities of cloud services: If you move your applications to a cloud and you use native services on that cloud, you’re now coupled to that cloud. This does not mean you can’t move the application again, but it will cost you time, money, and of course risk. You’re not technically locked in, but it won’t be cheap to move to a different provider. So you may feel locked in.

The truth of the matter is that all major public cloud providers come with the lockin trade-off. Although you can certainly write and deploy applications to a public cloud provider that are portable to similar platforms on other clouds, your applications won’t reach their full potential if you don’t use those native cloud services that make moving difficult.

You’ll lose integration into security services, governance services, high performance, and cost efficiency. In other words, unless you accept some lockin, your applications won’t take full advantage of the new cloud host.

To make matters worse, no two public cloud providers are the same in terms of the native services that they offer, and that is what locks you in. The promise of open cloud platforms have been functionally replaced by very good, but very proprietary, public cloud platforms.

Although lockin is a price of effective cloud use that can’t be avoided, it’s not as costly as you might think.

First, you’re unlikely to move the applications off your chosen cloud once you’ve moved there and made the applications somewhat cloud-native. Although enterprises need to prepare for the possibility that a cloud provider may go away, or abuse you with price increases, there is little chance of that occurring as the market stands today.

Second, there is no good reason to move a workload to a public cloud without taking advantage of the native cloud services. If you want to make an application generic and live on a cloud, I advise you not to move it. The cost is way more than the benefit.

Third, lockin exists in the datacenter too. You’ve chosen various servers, operating systems, applications, appliances, and so on to get the specific results you need, and your applications typically are made native to them to exploit those desired capabilities. This is not a cloud-specific trade-off.

“Lockin” is still a bad word, and I understand why. However, like most things with technology, it’s just another trade-off. 


Copyright © 2017 IDG Communications, Inc.

How to choose a low-code development platform