Your multicloud attitude reveals more than you think

Multicloud gets discussed a great deal. I find, though, that a surprising number of businesses focused on regulatory constraints — which historically have not had a lot of internal app development — are still early in thinking about multicloud. The system architects’ thinking can be so early, in fact, that they don’t know exactly what multicloud could even mean, and what it can provide for them. On top of that, how people think about multicloud often maps against what area of IT they are from and how far along they are in their “digital transformation” journey.

Let’s unpack all that. First, what do I mean by “what multicloud could even mean”? Shouldn’t that have read “what multicloud is”? Nope, that wasn’t a mistake. You talk to different people and you get different definitions of multicloud. Witness a sampling of some vendors’ (sometimes self-serving) definitions:

• Cisco defined being multicloud as having workloads on more than one cloud, at least one of which was public.
• Avi calls multicloud the use of multiple cloud computing and storage services in a single network architecture.
• Red Hat says multicloud is the presence of more than one cloud deployment of the same type (public or private), sourced from different vendors.

Okay, so we can safely say that multicloud has something to do with more than one cloud. The exact flavor of definition can differ.

Let’s take another angle on this — what various flavors of multicloud can enable. Here the conversation gets more interesting and perhaps easier to map to business requirements. What might you be trying to get out of using multiple clouds? Here are some of the more common things that people seem to be thinking of when they say multicloud will some problems for them:

• Having workloads that move back and forth between different clouds (generally based on some kind of cost-based optimization).
• Having workloads on different clouds in order to minimize dependence on any one cloud.
• Having workloads that are deployed on one cloud with backup on another.
• Having workloads that are deployed on one cloud and burst to another.
• Having workloads that are architected to exist across multiple clouds.
• Having different workloads on different clouds in order to take advantage of the unique capabilities of the various clouds or familiarity of various teams to specific properties.

All of these sound reasonable at a high level but fit into one of two categories. The first four are very Cloud 1.0 / infrastructure oriented — they reflect thinking that is reminiscent of considerations in private data centers (pick the lowest cost gear, dual source the compute vendor, have a DR strategy, figure out how to manage demand peaks). The next two are more Cloud 2.0 — applications look different because of the services that are available above the infrastructure layer in various clouds.

 What innovation are you leaving behind by thinking with a Cloud 1.0 mindset?

What's become apparent again and again is the extent to which conversations about multicloud benefits with more advanced organizations tend more towards Cloud 2.0 benefits than with organizations that lag. A decent number of people out there still view cloud (and by extension multicloud) as an infrastructure discussion focused on lowering costs. But, a lift and shift to cloud doesn't tend to lower cost. Also, I've never met anybody that moved workloads back and forth between clouds based on cost differences, and the extent to which people have had success with playing one cloud provider off another on costs seems more anecdotal than statistical (though I acknowledge that exceptions exist).

Organizations that "get it" are focusing on how cloud is an enabler for their organization. They see that some teams need different tools from others, or for whatever reason grew up used to a specific toolset from one cloud over another. In these cases, the conversation shifts pretty fast to "how do I make sure that my people get what they need, but that we are still aware of their usage and able to keep things safe and in compliance?"

This means that with organizations that get more value out of cloud (what Turbonomic called "leaders in digital transformation") conversations are about how to embrace and manage heterogeneity in clouds, services, and applications. They are not about spot instance cost analyzers, in-deployment workload placement engines, or workload portability. Many places will discover that even with an open arms approach to the various clouds most workloads gravitate to one place… that's okay! Others may find that various teams have almost religious fervor around their specific cloud choice… that's also okay. The important thing is that all those teams can get their work done.

If you are focused on cost containment it might make sense to take a step back and ask questions about what else your organization COULD do. Cost is an important consideration in any business, but not to the exclusion of everything else. What innovation are you leaving behind by thinking with a Cloud 1.0 mindset? At this point, there is a lot of expertise and a decent set of tools that can help simplify the management of the Wild West that multicloud could be for your organization… it's definitely possible to support technologies your teams need and be safe doing it.