Multicloud is a more polarizing concept than I once thought. Because multicloud is an overwhelming trend these days, I often hear both sides of the debate about whether multicloud is the next evolution of cloud. Or will it simply create new problems we must later solve?
Complexity adds cost and risk
Many argue that multicloud can create more problems and thus cost than it’s worth. Multicloud does come with additional complexity that is expensive and needs more resources to manage.
It’s true, you must address multicloud complexity with some layer of technology, such as providing platform service abstractions. Although it comes at the cost of complexity, the core benefit of multicloud is its ability to select the best-of-breed cloud services.
Which is a more negative value, and which is more positive?
In the value models I’ve done, the benefit of leveraging best-of-breed technology usually wins out over complexity. Difficult problems require the latest and greatest technologies to create innovative solutions, and that typically means multicloud. For instance, developers might need a specific type and version of an artificial intelligence system to create a system that will be core to the future revenue production of the company. If we’re forced to use a single cloud provider’s AI offering, we may miss the additional value that other technologies on other clouds could bring to the table.
In my estimation, it’s a no-brainer. Granted, there are a few outliers, but the value models that I see suggest that multicloud’s ability to support best-of-breed solutions will bring far more value than its offsetting complexity costs. Again, this is not always the case. But if you run the numbers for your own use of multicloud, you’ll likely find that having more choices often translates into major innovative value for the company moving forward.
So, for this one, most of the complexity arguments for avoiding multicloud are wrong—at least when it comes to supporting the use of high-value, best-of-breed technology.
Multicloud does not remove lock-in
Those who promote multicloud to avoid cloud provider lock-in do not see the big picture. They argue that leveraging the capabilities of a single cloud provider, such as serverless, auto-scaling, AI, or other features, may be the best way to go. Also, they believe cloud lock-in is something you’ll have to deal with no matter if you use multicloud or not.
It’s interesting to note that many who make this augment work for cloud providers. Most people are also surprised that I agree. Multicloud was never about avoiding lock-in—at least, lock-in in the way that I and other cloud experts see it.
Whenever you localize an application or data set for a specific cloud provider, you lock yourself into that provider. It doesn’t matter if you leverage one, two, or three public clouds at the same time (aka, a multicloud). Just the fact that you have other cloud providers attached to your enterprises means that moving applications written around specific native-cloud APIs and other services will not be easier or less expensive.
This news may burst the bubble of many multicloud advocates who have “remove cloud provider lock-in” on their slide decks to promote multicloud. If that’s you, multicloud is not immune to provider lock-in unless you’re willing to spend a great deal of money to avoid it. Otherwise, it’s just a part of effectively leveraging the native features of any cloud provider.
These are just two multicloud arguments, and I’m starting to hear many people taking sides. That seems a bit silly to me. Multicloud has always been about the “why” and the “how” and not about compiling lists of “why not.” For now, it’s easier to leave the polarizing discussions to those who don’t really have to make multicloud solutions work for the business.