Hybrid-multi Cloud: An Elevator Architect’s View

While of us mortals are still busy migrating existing applications to the cloud or perhaps building new cloud-ready applications, the marketing departments haven’t been sleeping at the wheel and are touting stuff like multi-hybrid-cloud computing (or was it hybrid-multi?).

The cynic in us will quickly conclude that chasing ever more shiny objects is easier than delivering something simple, but working. So, let’s not be blindsided by the glow of new buzzwords and cut through the hype to translate the buzz into architecture insights. While some detailed articles on Multi Cloud vs Hybrid Cloud and a set of patterns from our friends at Google Cloud are helpful, they don’t quite crystallize the architectural essence of the options we have and the decisions we need to make.

Hence, it’s useful to take the point of view of an architect who rides the Architect Elevator: what key decisions, constraints, and assumptions are baked into the solutions? What options do you have and what decisions do you need to make? What are each option’s benefits and costs, both in Dollars but also in complexity and lock-in? Let’s go have a look!

First, let’s segregate hybrid from multi. As easy at this may seem, one already encounters a reasonable amount of confusion and conflicting definitions. Let’s start very simple:

Now some folks, including GCP, consider on-premise to be part of multi-cloud (“A multi-cloud setup might also include private computing environments”). While technically the two are surely related (“on prem is just another data center”) if you count hybrid into multi, then there wouldn’t be any need to use the term multi-hybrid. Already confused? Let’s look at things from a different angle.

Whatever the technology, the intentions and drivers behind hybrid and multi are quite different. Hybrid cloud is a reality for enterprises: despite cool stuff like AWS Snowmobile no CIO will wake up one morning to find all of his or her workloads in the cloud. So, you’re bound to have something “out” and something still “in”, and the two more likely than not need to interact.

Hence, the core of a hybrid cloud strategy is “how to slice”, i.e. what workloads should move out while which other ones stay on premise. We’ll reserve that discussion for another post.

In contrast, a multi-cloud strategy is an architecture choice you make. Examining common multi-cloud approaches and the motivations behind them helps is make these choices.

To better understand the motivation for multi-cloud, it’s good to segment the technical platform architecture into common scenarios. What I have observed as packaged under the slogan of “multi-cloud” generally falls into one of the following categories:

A higher number isn’t necessarily better in this comparison – it’s about finding the approach that suits your needs and making a conscious choice.

If enterprise has taught us one thing, it’s likely that reality rarely matches the slide decks. Applying this line of reasoning (and the usual dosage of cynicism) to multi-cloud, we find that a huge percentage of enterprise multi-cloud is the result of poor governance and excessive vendor influence. It basically means that you have some workloads running in the orange cloud, some others in the light blue cloud, and a few more under the rainbow. You don’t have much of an idea why things are in one cloud or the other, or, more likely, you started with orange, then you received a huge credit from light blue thanks to existing license agreements, and some of the cool kids love the rainbow stuff. And if you look carefully, you may see some red peeking in due to personal relationships and a heavy sales push.

Strategy isn’t exactly the word to be used for this multi-cloud setup. It’s not all bad, though: at least you are deploying something to the cloud! That’s a good thing because before you can steer you first have to move. So, at least you’re moving.