2 mistakes that will kill your multicloud project

Multicloud should be easy, right? I mean, it’s just deploying and managing more than a single public cloud. This has unfortunately not been the case. As more enterprises deploy multicloud architectures, some avoidable mistakes are happening over and over again. With a bit of understanding, perhaps you can avoid them. Let’s review the top two:

Not designing and building your multicloud with cloudops in mind. Many enterprises are deploying two, three, or sometimes more public clouds without a clear understanding of how this multicloud architecture will be managed long term.

When a multicloud deployment moves to production, there’s a great number of cloud services caused by leveraging multiple public clouds with redundant services (such as storage and compute). It all becomes too much for the cloudops team to deal with. They can’t operate all of these heterogenous cloud services as well as they should, and the quality of service suffers. It also places way too much risk on the deployment in terms of security and governance operations.

There are a few ways to avoid this. First, don’t do multicloud if you’re not willing to step up to the operational needs. Stick with single cloud deployments only. This takes all best-of-breed services off the table and reduces the value in using cloud at all. The second, and the proper approach, is to automate pretty much everything and to leverage abstractions (single pane of glass) to manage the complexity and still provide best-of-breed benefits.

Choosing “cloud native” everything. Keep in mind that tools that span the public clouds are the most useful. You can use the same interfaces and automation from one cloud to another in your multicloud.

This seems like the obvious choice, but many enterprises moving from single to multiclouds are keeping the native tools that came with a particular public cloud, such as security and operations tools. Companies that opt to keep specific management and monitoring tools for AWS, Microsoft, or Google will have to learn and leverage a tool per public cloud. Not very efficient.

Avoiding this problem is easy to understand, but not so easy to pull off. Although cloud-native applications are fine, only using native tools for all sorts of management and security tasks is just not a good idea. You’ll need people who understand each tool, there won’t be intercloud communications and coordination, and automation will have to occur in multiple places instead of one. The solution is to look for tools that span clouds and provide consistent interfaces across clouds.

Multicloud is still an evolving science. Public cloud providers are not offering good guidance and tools because it’s not in their best interest to push their customers into multicloud. However, if they try to lead you to a design pattern that increases your complexity, costs, and risk, avoid that path.