Why Multicloud Does Not Avoid the Dreaded Lock-In

Learning about the reality of how all this cloud stuff really works.

From “An Insider’s Guide to Cloud Computing”

With voiceover and commentary.

“Multicloud avoids lock-in.” That phrase is often sold as an upside to multicloud, and you can kind of see the logic here, but the reality is far more complex. If you have a multicloud that’s made up of more than a single public cloud provider, then you have access to different native cloud services and can thus avoid lock-in. Right?

Wrong. There are shades of gray. First, it’s easier to move from one cloud provider to another if that cloud provider is already onboarded as part of your multicloud deployment. So, if you build applications and databases on AWS, which is part of your multicloud along with Microsoft and Google, then it will naturally be easier to move those applications and databases between public clouds that your multicloud already supports. This is just a reality, and it’s an upside, but not by much. You’re not actively avoiding lock-in; it’s just a by-product of preexisting relationships with other cloud platforms that makes moving applications and data a bit easier.

Second, you don’t really avoid lock-in. If you use a cloud provider’s native features to localize applications and databases, then moving to another cloud means the code and databases still need to be modified to accommodate another cloud provider’s native cloud services. You’re just moving from one walled garden to another. You must adapt application processing, governance, security, database access, and so on to accommodate the “new” public cloud provider’s services. Of course, we can use more portable technologies such as containers and build applications that take a least common denominator approach to development, which allows for better portability.

However, containerization of more traditional applications costs more time, money, and risk. Leveraging the least common denominator approach means that your application will provide substandard performance on all platforms, albeit the application will be much easier to move between platforms. When given the choice, most will want native performance and not want to sacrifice that performance for platform portability that they’ll likely never utilize.

There is always a way to toss money at an architecture to avoid lock-in, which will resolve parts of the problem. However, tossing money at the problem means that the business case for building portability takes a hit, considering that you’re spending more resources to achieve it. Most applications and databases are neither business critical, nor will they ever move. This is how the upside of avoiding lock-in becomes a nonissue. We talk more about this when we hit the downsides of multicloud a bit later in this chapter.