Lock-in is the dirty little secret of public cloud computing. Cloud engineers have whispered it for years, but more and more people are speaking up now.
I was impressed by this CIO article about 10 dark secrets of cloud by Peter Wayner (CIO is also part of IDG). You should read it for a few reasons.
First, it’s not often that the press discusses the downsides of cloud computing—it’s always a bit of a media lovefest. I’m often taken aback by the lack of dissent in general, specifically when I get pushback for pointing out issues with cloud computing that should be understood by now.
Second, the points made in the article are well thought out and reflect other posts I’ve done over the years on cloud topics such as performance, cost, and lock-in. Don’t get me wrong, cloud has very few issues. However, the issues it does have need to be understood prior to jumping in feet first.
Let’s focus specifically on what Wayner says about lock in: “At first glance, selling a commodity operating system on commodity hardware should be a commodity business. But somehow the cloud world is surprisingly sticky. Even when your data or the services you create in the cloud are theoretically portable, simply moving all those bits from one company’s cloud to another seems to take quite a bit of time.”
“Cloud native” is a popular rallying cry these days. The bad news? Cloud-native applications have built-in dependencies on their cloud hosts, such as databases, security, governance, ops tools, etc. It’s not rocket science to envision the day when a cloud-native application needs to move from one cloud to another. It won’t be easy.
Yes, it’s possible to move the application, but the problems that arise because of cloud lock-in are much more real than the industry lets on. Most enterprises don’t discover the lock-in limitations until they move from one cloud to another. Move requirements typically arise due to cost and performance issues, another set of points Wayner makes in his article.
With all that said, don’t use lock-in as a reason not to move to the public cloud. We’ve dealt with lock-in issues in the past, and on multiple platforms. This is no different. Lock-in is just another trade-off of cloud computing. As such, it needs to be understood and managed.
Some people point to portable cloud applications that avoid lock-in. These typically involve a non-native, least-common-denominator approach to application development, where you avoid lock-in by avoiding native services altogether. They do provide better portability, but in general, they don’t work well everywhere they should.
Containers are another approach to portability. I’m a big fan, but let’s acknowledge that containers require additional cost, effort, and risk to containerize applications. Plus there’s additional work when moving them from native cloud to native cloud.
Does a magic answer to cloud lock-in exist? Not yet, and perhaps never. The good news/bad news is that we’ve faced insurmountable IT problems in the past and learned to work around them. It’s 2021, and we’ve been at cloud computing for well over 10 years. It’s time to look at the advantages and disadvantages of cloud lock-in and manage both. It’s also time to realize that the best solution won’t be perfect, but it can be the best imperfect solution that meets the enterprise’s most critical needs.
