3 Ways To Screw Up A Multicloud Deployment

We’re experienced with multicloud, but we’re also making common mistakes. Make sure you plan common services and have all your people on board.

I guess I could place some stat here that shows multicloud is the large majority of public cloud deployments out there, but there are lots of other places to see that. We know it’s a common approach for enterprises to move to plural clouds versus single-cloud deployments. Enough said. 

The mistakes I see in multicloud deployments are not at all what you would think. You likely believe these errors are related to some complex technology being deployed incorrectly, but they are actually part of simple, well-understood issues. I assume it happens because people lack sound cloud computing architecture experience and are cobbling these architectures together. In other words, pilot error.

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

A lack of common cloud services and planning

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

This is now beyond a best practice. It’s a solid reality when you’re planning, building, and deploying a multicloud. A layer of common services, such as security, finops, observability, etc., is needed above all cloud providers. Don’t attempt to leverage whatever native tool is provided that only functions with a single cloud provider. You’ll end up with way too much redundancy, heterogeneity, and complexity.

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

A fixation on avoiding vendor lock-in or costs

So, why are we doing multicloud? The biggest misunderstanding is that multicloud will let us avoid vendor lock-in and will save us money. Neither is true. 

Let’s take lock-in first. If you 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 likely leveraging the best-of-breed native features and services on that cloud provider, such as security APIs and other native services that applications need. There is really no other choice but to do that. If you don’t, your application will not provide the same performance, functionality, and reliability, and you’ll have a bigger cloud bill.

However, it comes at the cost of some lock-in, considering that moving applications from one cloud to another means changing a great deal of code in the process. Thus, multiclouds don’t avoid lock-in, as a rule.

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

Many argue that dealing with several public cloud providers may put you in a better negotiating position for preferred cloud pricing. Even with that, I’m not seeing significant bargains to be had with this approach. Let’s face it, everyone has a relationship with more than one cloud provider now—you’re not special.

Not dealing with people issues

My advice is clear: Before you attempt moving to multicloud (or any other technology disruptors), you must have the culture and skills to be successful. 

A great many IT teams do multicloud planning and architecture near perfectly, but then they deploy their multicloud to a group of people who don’t understand why it’s there, what it does, or how to operate it. I bet more than a few heads are nodding right now.

The truth is, technical people, including myself, like solving technical problems and don’t always deal well with people issues, or they avoid them altogether. Coming from someone who’s made that mistake more than a few times, you must prepare people for change in terms of understanding, adding new skills, and seeing how people interact and function (e.g., operations models).

Ignore this at the peril of your multicloud deployment.

By: David Linthicum
Originally published at InfoWorld

Source: Cyberpogo