3 surefire ways to kill your multicloud deployment

Flexera’s report confirms that multicloud deployments are increasingly a two-cloud race between public cloud providers. Among all respondents, 50% of enterprises have significant workloads on AWS, and 41% run those significant workloads on Azure. Google Cloud has a 22% share. What they all have in common is explosive growth in 2020 and, I’m sure, continued growth this year. 

To be honest, I don’t care who is winning the race to be the top public cloud provider. It’s more about how you leverage these clouds in ways that allow you to solve business problems.

The reasons for moving to multicloud are not so much to avoid lock-in but to have choices for building applications in and migrating to the cloud. Most enterprises use two or more public cloud brands, meaning multicloud. But you can kill a good multicloud deployment unless you consider these three recommendations.

Choose common, cross-cloud tools. The worst thing you can do when building a multicloud solution is to silo tools and technologies within each cloud. This includes security, governance, operational tools, etc.

The end result is a tool for each public cloud. When it all gets handed over to the cloudops teams, they have to deal with at least nine tools, which require different skills and training. The complexity typically means that the final multicloud deployment is not realistically operational. You need to find common tools that work across clouds.

Understand the cost of adding clouds. If you’re supporting two public clouds, the cost of adding one more should be equal, right? Wrong. It really depends on what you’re doing with that specific public cloud.

If you have 100 applications and connected databases on one cloud and 150 on another, if you add a public cloud that has only 5, the operations cost per application goes way up for that public cloud provider. So, those who want to add a new public cloud to our multicloud need to prove solid, cost-effective reasons. Keep in mind that ops costs for each cloud provider are mostly fixed.

Avoid a culture of unencumbered choice. Multiclouds mean choice—choices in security services, application development tools, databases, etc. However, selecting different net-new cloud services increases complexity, and complexity increases risk and cost.

This is a trade-off. We want developers and other innovators to pick whatever best-of-breed services they would like to use. However, if they move to new services, you’ll likely have redundant services to operate on the back end, such as multi-security services, multi-database services, etc.

The idea is to not be tyrannical about more heterogeneous cloud services, but to understand the trade-offs that have to be managed. At the end of the day, there should be an agreed-upon set of common services to reduce complexity, cost, and risk.

More to come. We’re finding things not to do on a weekly basis.