Unfortunately, multicloud is a poorly defined term in the industry. There are some use cases that are unambiguously multicloud setups — for example, running simultaneously in Amazon Web Services, Google Cloud Platform and Azure. But there are also many gray areas — where is the line between multicloud and hybrid cloud? What are the functional differences between the two?
At Mist.io, when we think about multicloud and the complexity it brings to deployments we don’t actually think in terms of number of vendors or public cloud providers but rather our ability to manage the entire deployment with a single API and get a global view of the deployment in one place. This means that an organization could be having a multicloud-like experience even on just one cloud provider.
There are two deployment patterns we see, one that we call “island deployments” and the other “Russian doll deployments,” both of which behave very much like multicloud even if there is only one cloud provider involved. Both patterns involve deployments on a single cloud that nonetheless require separate management and end up having many of the same complexities as operating in multiple public cloud providers. Most users with an island deployment or Russian doll deployment would almost certainly not say that they were using multicloud, and yet they have to deal with many of the same issues that someone in multiple public cloud environments would.
Here’s more about the two deployment patterns, why organizations use them and the complexities they create.
Many organizations segment their workloads to such an extent that they are essentially different clouds. The API calls might be the same, but there are different accounts, different use cases, different people connecting to each cloud and running different types of workloads.
If you have three completely independent Kubernetes clusters, one for production, one for staging and one for development, are you in multiple clouds or a single cloud?
In another example, OpenStack users rarely upgrade old deployments, and as a result, end up using multiple versions of OpenStack. When you consider that they might have production, staging and dev environments for each version of OpenStack, the number of OpenStack installations can easily get into the double digits. Is that still a single ‘cloud?’
Each AWS region has its own regional API endpoint, and you can’t manage all of your resources across different AWS regions in a single API call. So are you multicloud if you have multiple AWS regions?
While these scenarios don’t meet the usual definition of “multicloud,” they present many of the same challenges, like lacking central management and visibility capabilities. If you have this “island” approach, you might not be technically multicloud, but your actual experience of managing your cloud environment(s) will be more similar to a multicloud approach than to a single cloud environment.
Russian Doll Clouds
This is more frequently seen in bare metal clouds, but can apply to any public cloud that allows nested virtualization. For example, I could create some AWS instances and then install OpenStack on top of those instances. At Mist.io, we’re doing something like this with Equinix Metal. We get bare metal from Equinix, then install VMWare vSphere on top of that, then OpenStack and then Kubernetes. We need all of these environments so we can test our integrations, and we use this environment for our testing and QA.
So is this one cloud? Or four? We have only one vendor, but there are a lot of environments on top of what that vendor is providing. Just because everything depends on the bare metal doesn’t mean that I can control all of the environments from a single API endpoint.
Most people who have an “island” or “Russian doll” deployment would say they aren’t in multiple clouds. But that doesn’t take into account how complicated these types of set-ups can be, and how much they resemble the situation when working with multiple cloud environments. There are similar challenges related to cross-environment visibility, management and control.
When discussing the challenges and complexities around operating in multiple cloud environments, it’s important to remember that some application architectures, even in a single cloud, present many of the same issues as a true multicloud deployment. This is one of the reasons the best way to think about multicloud is not as a yes/no binary but as a spectrum, with some architectures being ‘pure’ single cloud, some being clearly multicloud and many falling in a gray area in between. Doing so will help organizations not just be more successful with true multicloud deployments but also with their deployments on a single cloud that are nested and/or highly segmented.
Amazon Web Services, Equinix and VMware are sponsors of The New Stack.