Hashicorp on "Why Multi-Cloud?"

Mitchell Hashimoto (Hashicorp Founder and CTO) commented on Reddit on why certain corporations care about Multi-Cloud deployments. I have copied the original post below:

This is something I can provide very broad real world insight into. I routinely talk with dozens of users and paying customers that are multi-cloud (biased towards the Global 2000 size) and can share the real reasons why folks are doing this.

First, if you’re a small company, you probably don’t want to think about multi-cloud. Just focus on your one cloud, your account probably won’t be shut down (especially if you’re paying enough money), the cost you save optimizing across clouds won’t pay for the overhead (at first), etc. Just use one cloud. But I predict the time will come when multi-cloud becomes valuable. Read on!

But, if the company you work for plans on 1.) being a big company or 2.) being acquired (basically anything OTHER than staying a small private company), you should be mentally prepared that multi-cloud is coming for you whether you want it or not.

From a Global 2000 standpoint, most of those companies existed prior to the cloud existing (in a real, marketable, business-ready form). They’re usually coming from an extensive physical footprint, possibly multiple datacenters. So they start by adopting a single cloud. Systems are complex and therefore there is at least a multi-year period where they’re “multi-cloud” (or hybrid you may say) across cloud + physical. That encourages these companies to look for tools that can benefit both (such as Terraform or Vault, from our own portfolio).

But Global 2000s also acquire companies. Acquisitions are key to their growth strategies. Acquisitions aren’t usually contingent on what cloud platform you chose, so the dev/ops groups get whatever corp dev brings into the company. Surprise! Your company just acquired a company that is all-in on another cloud platform. You now have a choice: either spend a lot of time/energy migrating those workloads to your systems, or spend time/energy on supporting both. Usually it goes with the latter. Congratulations, you’ve now unexpectedly and forcibly become multi-cloud. Companies that have spent time preparing for this take it with ease, no problem; you’ve built the process and technologies to support any workload. Companies that went all-in on one cloud struggle and have a lot of pain ahead.

So let’s say that hypothetically you’re a big company and you aren’t doing acquisitions (or you’re focused on a single cloud). If you’re a big company, your IT spend is going to be considerable (a very easy $1M+ per year, very easy, we work with some companies spending orders of magnitude more). That much money motivates vendors. You pay Cloud A $500K per month? Cloud B is going to send some suits knocking on your door offering you the same resources for $400K per month guaranteed for 3 years. Cloud C is going to just give you millions of dollars in credit to “try” their platform. Clouds know once you have workloads on their systems, you usually don’t move off too easily. From a top-down executive perspective, its hard to say no to this. I was just at a big company in London where the cloud choice was made on this. One cloud sent an executive team to their office (from the US) and offered them millions in credits over an exclusivity contract (can’t use any other cloud) for 3 years, making their effective costs very very cheap. Guess what cloud that company chose? Yep.

Let’s go back to technology. Big companies run a lot of software and that software may have specific requirements. The most common case for multi-cloud I see early on is “we’re 90% cloud A but 10% cloud B because cloud B software runs better there.” The most obvious example: Active Directory. AD is easily the most common onramp onto Azure I see, its so easy to run AD on Azure (relative) and almost all big companies are built on AD systems.

Another technical choice: better high-level services. Some clouds have much better high level services than others regarding data processing, machine learning, etc. So sometimes specific teams (for example teams building ML models) may be motivated to use a certain cloud even if the built model will be run on a different cloud. This comes back to the question of: are you going to force all your dev teams to use your one true cloud? Or are you going to let them run their dev workloads (at least, if not prod!) on others? If the latter, how are you going to do access control, resource management, budgeting, etc.? It opens up a big can of worms that pushes you down the path of multi-cloud processes and tooling, again, even if its non-prod!

There is also the “vendor lock-in” thing. Its a real thing. But its not as huge of a thing as people claim. There is one company we work with that is 99% on one cloud. They have a full plan (technical to human) to migrating to a specific 2nd cloud in 6 months. Do they plan to? Not at all. But they do it for two reasons. One, if they acquire a company (they haven’t yet), they can support multi-cloud since their processes are built around it. Two, if their current cloud starts hard negotiating their reserved pricing, they have leverage, they can move.

And finally, just a real quick point: a common confusion is multi-cloud vs. multi-vendor services. The latter is way more common, especially at smaller companies. Tools like Terraform are often touted as “multi-cloud” and people ask questions like “Why would I use Terraform if I use only AWS?” And the easy answer to that is tools like Terraform allow you to manage anything with an API as code. For example: do you want to manage DNS, or CDN, or DBs, etc. (that maybe aren’t on AWS) as code? Terraform gives you the way to learn one config language/workflow to make that happen, even if 100% of your compute is on one provider. From a non-technical standpoint, this helps your organization start learning non-vendor-specific tooling, which better prepares you from a human standpoint for the future noted above.

I think the #1 value of multi-cloud is organizational: you build your core infra/app lifecycle processes (dev, build, deploy, monitor, etc.) around a technology-agnostic stance. As technologies shift, other clouds become important, new paradigms emerge, etc. your organization is likely more prepared to experience that change. This is something that is core to our ideology at HashiCorp, its point #1 in our Tao that I published 4 years ago! https://www.hashicorp.com/blog/the-tao-of-hashicorp

I hope that helps! A full list of non-hypotheticals. I promise that each and every point I’ve personally seen in at least 5 different companies.