What is Multi-Cloud & Why are Companies Adopting it?

Transcript

Armon Dadgar: One thing that users and customers ask me all the time is, “Why should I bother with multi-cloud? One cloud is hard enough. Why don’t I just pick one, like Google, and just get really good at Google? They all have similar IaaS services, and they’re all catching up on some of the higher-level stuff. Yes, there are some slight differences, but why bother with multi-cloud?”

That’s a common sentiment, and you gave a really good answer: Maybe you don’t choose multi-cloud; multi-cloud chooses you. Talk through that.

Mitchell Hashimoto: I think the reason people give most frequently for adopting multi-cloud is to avoid vendor lock-in or a price lock-in or something like that.

What’s funny is that’s almost the least common reason people think about when they go multi-cloud. I think that’s such an optimization that it’s not the right thing to think about first. That’s unrealistic, practically.

Realistic reasons for multi-cloud

The better way to think about it is that, especially at the enterprise level, most companies that are adopting cloud are moving from something they had before—physical servers or something. And so you’re immediately in a multi or at least hybrid cloud environment. And you can call it multi-cloud or call it hybrid cloud, but the challenges you have are pretty much the same. And so that’s one of the reasons.

Another reason is acquisitions. If your company decides to buy another company, and you’re on one cloud vendor and the company you’re buying is on another, the company’s not going to cancel the acquisition.

They go to the central IT Ops, DevOps, whatever the team is, and say, “Figure it out; integrate this company into ours.”

And then another reason is pricing pressure. At a certain scale, especially if you’re an enterprise that’s spending millions of dollars on cloud, you will get credits or some sort of subsidy that pushes you one direction or another. And for a CFO or management, a free couple million dollars is pretty hard to say no to. They’re going to go to the team and say, “Let’s use this as best we can.” So you’ll be stuck there.

And then the last reason really is just enabling your teams to use best-of-breed services. So at any given moment, certain clouds have better AI services or better data processing. And you want your teams that are working on those problems to be able to use the best tools possible. And saying, “You can only use this one cloud platform,” is just so restrictive. And so the multi-cloud will find you.

Armon: It chooses you.

Mitchell: Yeah.

Armon: I think that last point, around differentiated service, does get underplayed. It’s easy to take a 100,000-foot view and say, “Hey, they kind of all offer the same thing.”

But I think what we see in practice is there’s really good data services in Google, and so you’re going to have a data team that’s like, “Maybe I want to go leverage that because I’m sort of isolated from the rest of the business. I can just go use BigQuery and some of these data pieces on my own,” versus, “If I’m in the business of managing SharePoint for the business, even if all my apps are running in AWS, there’s value in me saying, ‘It’s Microsoft’s problem to manage SharePoint. I really don’t care.’”

So I think at a 100,000-foot view, maybe you don’t see the differentiation, but when you zoom in, it’s there, and in practice the practitioners will find it and use it.

The 4 definitions of “multi-cloud”

Mitchell: One thing I see happen a lot when people bring up multi-cloud is a confusion in definition. When you say “multi-cloud” to a room of people, usually there’s a handful of people who have totally different thoughts of what multi-cloud is. But I only believe in one of them strongly. The other ones are somewhat real, but one is very real.

The 4 definitions are:

• Workload portability
• Workflow portability
• Data portability
• Traffic portability

The way I look at those is: Workload portability is the idea that you write your app once and run it anywhere. So the same app you write for one cloud could just run anywhere. And that’s very difficult to achieve, because you want to integrate with these high-level services that a cloud provider provides. Native logging; Lambda is a good example. And you don’t want to dilute the cloud to the least common denominator. You really want to write workloads for a single cloud.

The second one is workflow portability, and that’s the one I strongly believe in. That’s the idea that you could maintain a consistent workflow across clouds for deployment, security, networking, and so on. And I think that’s very achievable. That’s what our products do: workflow-level portability.

And there’s data and traffic. Data portability is being able to move data from one cloud provider to another. The biggest thing against you there is the speed of light.

Armon: And that’s where people are talking about things like data gravity. Once you’re moving 100TB, it costs a lot of money and it takes a lot of time.

Mitchell: It’s faster to load it in an airplane.

Armon: Exactly.

Mitchell: The last one is traffic portability, which is pretty real. If you have geographically dispersed users, you can route to the nearest cloud provider that could service them. And that’s pretty reasonable.

Armon: You might see examples of each of those. But in practice you see workflow portability, right? If you standardize on tools like Terraform, you can provision across multiple clouds pretty easily. Data portability you almost never see in practice. The cost is too astronomical. Traffic portability, if you have copies running in multiple clouds, you just do traffic shaping, it’s relatively achievable. But you really only see workflow and traffic in practice.

Get the workflow right from the start

Mitchell: A funny thing I see happen, now that we’ve watched this multi-cloud journey for a few years, is that if you don’t optimize for workflow portability up front, it’s really painful later.

The cloud has been around long enough now that there are cloud-first startups that are becoming public companies. They’ve been all one cloud for 7 or 8 years. And they’re now big enough to buy companies, and they’re buying a company that’s on Azure or something. And that experience of this 800-person company having to suddenly deal with going from n = 1 to n = 2 is extremely violent.

We’ve seen multiple times where entire DevOps teams or security teams just leave the company, because they view themselves as a single-cloud organization, and this is too violent in that process way.

I always say, “Don’t optimize multi-cloud in terms of using multiple at first, but optimize the workflow right away.” Even if you’re a new company, get the workflow right to use a single cloud and stick with a single cloud for as long as you can. But at least when that goes from n = 1 to n = 2, you’re way better equipped to handle it.

Armon: That that seems fair. Summarizing what you said, sometimes multi-cloud isn’t necessarily a choice people make, it’s that it happens because of an acquisition or merger, or you just get credits and it’s a good deal, or there’s some differentiated service. So it happens organically without being a conscious choice.

And from our experience, you should optimize for workflow portability, and acknowledge that workload portability and data portability are kind of myths. There’s real cost associated with trying to architect for those.

Mitchell: Yeah. There are fear-based reasons and practical reasons.