3 ways to screw up a multicloud deployment

I guess I could put some stats here showing that multicloud is the vast majority of public cloud deployments, but there are plenty of other places to look at that. We know it’s a common approach for enterprises to move to multi-clouds instead of single-cloud deployments. Enough talk.

The errors I see in multicloud deployments are not at all what you would think. You probably think these errors are related to some complex technology being implemented incorrectly, but they are actually part of simple, well-understood problems. I guess it happens because people lack a solid background in cloud computing architecture and they are improvising these architectures. In other words, pilot error.

Let’s look at three of the most common mistakes, so we hope you can avoid them.

a lack of common cloud services and planning

It should be well understood by now with the advent of supercloud or metacloud, but not building common services logically on top of public cloud services is still a common mistake that costs many companies millions.

This is now beyond a best practice. It’s a solid reality when you plan, build, and deploy multicloud. A layer of common services, such as security, finops, observability, etc., is needed on top of all cloud providers. Do not try to take advantage of any native tool provided that only works with a single cloud provider. You will end up with too much redundancy, heterogeneity, and complexity.

Companies that make things much more complex in terms of operating costs, security, monitoring and tracking, end up spending 2.5 times more on all of their multicloud operational services, and they don’t perform very well.

a fixation on avoiding supplier or cost blocking

So why are we doing multicloud? The biggest misunderstanding is that multicloud will allow us to avoid vendor lock-in and save us money. It’s not true either.

Let us first consider blocking. If you’ve done the common sense math in your head, you already understand that if you’re building an application on a specific public cloud provider, you’re probably taking advantage of that cloud provider’s best native features and services. such as security APIs and other native services needed by applications. There really is no other option than to do that. If you don’t, your application won’t provide the same performance, functionality, and reliability, and you’ll have a higher cloud bill.

However, it comes at the cost of some lock-in, considering that moving apps from one cloud to another means changing a lot of code in the process. Therefore, multiclouds do not prevent blocking, as a general rule.

Now, let’s look at the cost. In no world is multicloud less expensive than single cloud deployments. You’re dealing with many more cloud services to manage and more diverse skills you need to hire. Also, from support to security costs, everything is higher. Multicloud should return more value to the business for the added costs, but that’s another problem.

Many argue that dealing with multiple public cloud providers can put you in a better position to negotiate the price of your preferred cloud. Even with that, I don’t see any significant bargains with this approach. Let’s face it, everyone now has a relationship with more than one cloud provider: you’re not special.

Not dealing with people’s problems.

My advice is clear: Before you try to go multicloud (or any other technology disruptor), you need to have the culture and skills to succeed.

A lot of IT teams do multicloud planning and architecture almost perfectly, but then deploy their multicloud to a bunch of people who don’t understand why it’s there, what it does, or how to operate it. I bet more than one head is nodding at this point.

The truth is that techies, myself included, like to solve technical problems and don’t always treat people’s problems well, or avoid them altogether. Coming from someone who has made that mistake more than a few times, you need to prepare people for the change in terms of understanding, adding new skills, and seeing how people interact and function (eg, operating models).

Ignore this at the risk of your multi-cloud implementation.