A Multitude of Multi-cloud Monikers

…decluttering the Hybrid and Multi-cloud conundrum

It is a very regular occurrence for me to have a conversation with a customer about Multi-cloud. What is it exactly? Can it add value? And, what do Supercloud, MetaCloud and Multi-cloud 2.0 mean? I had a customer recently who was considering architecting two landing zones in different Hyperscalers because they believed they could move workloads from one to the other and back again based how much things cost on a particular month, thereby saving money. It’s a bit more complicated than that and not really practical to do this:?a) technically and b) migration cost-wise.

This then, is an attempt to clarify the art of the possible.

I think it helps to give some definitions at the outset. I like this definition by Gartner:

“Hybrid cloud computing is the use of multiple cloud computing services. In most cases, a public source and a private source are involved. Multi-cloud computing refers to the use of cloud services from multiple public cloud providers for the same purpose”- Gartner.

[Gartner, Cloud Computing Primer for 2019, January 2019]

And then there is this definition from VMware which is a little broader. They view a VMware private cloud in the same arena as a Hyperscaler and drop the reference to Hybrid. Completely understandable from when you start to consider the continued adoption of VMware On services like AVS (Azure VMware Solution):

“Multi-cloud is a model of cloud computing where an organization utilizes a combination of clouds, which can be two or more public clouds, two or more private clouds, or a combination of both public and private clouds.”

[VMware 2022]

What is key is to agree the terminology and definition with your customer at the outset.

For the purposes of this summary, I will use the Gartner definition as it seems to be more widely adopted by Forbes Tech Council and Everest among others.

What Clouds are we seeing out there in the market from our customers? From my experience we are seeing very few Multi-cloud by design implementations. Remember for it to be Multi-cloud by the Gartner definition there needs to be the same type of workloads hosted in two Hyperscalers. If you have one as a primary and a secondary providing a different function like IIoT or ML then this would be considered a Hybrid cloud scenario rather than Multi-cloud. There has to be an interchangeable aspect for it to be Multi-cloud. This is where these additional monikers come in – Multi-cloud 2.0 and Supercloud and Metacloud. For this interchangeability there needs to be an abstraction layer. We can see this happening with containers. Azure have their own K8S platform AKS. However there are others which can run on private and multiple public i.e. OpenStack and Tanzu. If this abstraction layer exists away from the Hyperscalers then Supercloud can exist for Kubernetes. Sort of. There’s still some complexity in moving but it is possible.

These terms are not new – Supercloud was coined by Cornell back in 2016 and there’s a nice demo with an IaaS machine.

Metacloud and Multi-cloud 2.0 and Abstract Cloud mean the roughly the same as Supercloud. Though there will be nuances up for debate most likely.

My question is: without this abstraction layer to unify similar workloads that allow customer choice – is Multi-cloud desirable? What is the value? I often hear the old adage – eggs all in one basket. Sure. But if one of your baskets fail you are still left with half a basket that may or may not work properly without the other basket. And, in this age of built-in availability zone and regional and geographic redundancy in the Hyperscalers would there ever be the complete loss of a basket for an extended period of time? I’m not fully convinced by this.

I completely understand the use of an additional Hyperscaler for Disaster Recovery purposes – but then we are not using two Hyperscalers for the same purpose – we are simply using one for the workload and one as DR.

Technology drives Innovation and I can see how it would be desirable to switch between clouds because this innovation and use of technology can give a company a competitive advantage. However, few companies would change their bank account provider or their accountant every month. First of all – it has administrative overhead, and secondly, would it really make a difference to their ability to win business?

The blockers to being able to switch between Hyperscalers as I see them are:

1.??????The Architecture. There are similarities between how the Hyperscalers are architected but there are also many differences. You would need to have multidisciplinary teams with detailed specialist knowledge to provide the best security and capability for your landing zone. And, the ongoing operations.

2.??????The Native tooling. With the Native Hyperscaler toolset you get many up to the minute innovations and processes and technology that can provide value. The toolset is very different across each Hyperscaler. And it is not just one piece of tooling – it is a whole Service stack that needs to be used and understood.

3.??????Hybrid and Multi-cloud Management tooling. This isn’t really a blocker as such but in order to manage the Multi-cloud properly you may need some additional tooling and processes. Yes, additional tooling. You also must make sure that the toolset is good enough to do the task required. And the processes you have in place for DevOps, Operations, Architecture, Security are all aligned with the toolset. It’s not about throwing yet more tooling at a problem and solving it - you are adding complexity that still needs to be managed in order to make things better. So, this can be a partial remediation to the first two blockers, but in failing to be considered properly – it can also be a blocker in itself.

With the above problems, you may come to the conclusion that Multi-cloud as we define it in terms of Gartner is not conscionable in terms of business value. I would say that things are not always so black and white and there may still be some use-cases where Multi-cloud makes sense. Imagine you are a SaaS provider – that’s your business. To provide your service on different Hyperscalers may be desirable outcome and may give you a competitive advantage in the Market as you can sculpt your offering and integrations to suit the customers Hyperscaler preference. Or even for redundancy.

You can also abstract away and allow for containers in the Multi-cloud but again you are not getting all that Hyperscaler Innovation and goodness in the platform. This is tempered by the fact the Hyperscaler flavours of Containers give you additional capabilities. AKS, AKS Edge Essentials, and any enabled K8s can be nicely managed by Arc in Azure. So here you also get more by sticking with one primary Hyperscaler.

In contemplating a Multi-cloud (by Design) Strategy the three key points that I believe should be considered are:

1.??????Really understand your business context.

2.??????Focus on the real value.

3.??????Think of the ongoing operations: 1-year, 3-years, 5-years…

If after this reasoning it still makes sense - then fantastic - Multi-cloud by design may help you. I would surmise though, that this is most likely the exception rather than the rule. Come back to the maxim that is hardwired into us as Architects – ‘what is the problem we are trying to solve?’ Is there a problem? Is there enough of a problem to justify the complexity of tooling and processes?

Hopefully I have canvased some issues around Multi-cloud in the above. It would be great to have some discussion on this. If there is an angle I haven’t thought of – I would love to hear it.

These views are my own.