What’s the real value of multicloud redundancy?

I’ve been hearing the arguments about the use of multicloud: best-of-breed cloud services, cost performance optimization, and, of course, redundancy by leveraging more than a single cloud provider brand.

Businesses are using one cloud as a primary and a second cloud as a hot standby. Most are assuming that there will be a major outage or denial-of-service attack with Cloud A and they can fail over to Cloud B. This is multicloud redundancy and it is gaining in popularity now that multicloud is a thing. 

But it’s not the only solution. Most major cloud providers offer secondary data centers for high availability or the ability to leverage physical regions to provide redundancy. Relying on the business continuity/disaster recovery capabilities at a second cloud provider level for most outages and attacks will not stop your first cloud provider from…well…providing.

Although there have been a few public cloud outages over the years, there has been very little impact on public cloud customers. Moreover, public clouds have much better uptime records than most internal systems.

So, is there value in adopting multicloud redundancy?

It’s not free. Multicloud redundancy requires that you set up a primary version of the application and data set on a public cloud provider, then do it all again and set up a secondary hot standby on a second public cloud provider. It’s not twice the money to pull off this trick, but it’s about 75% to 85% more, on average.

If setting up a single application and data on a single cloud costs $1 million to place in production, opting for multicloud redundancy would cost as much as $1.85 million. This is just to get to deployment. Ops and secops would be about twice as much as well, ongoing.

Even though it costs about twice as much, you get a system that will never stop providing services to the business, right? Sure, I guess if you look at how these heterogenous redundant systems operate in a perfect world, and that you would suffer some ungodly loss of money when systems were not working (say $1 million an hour), then they are perhaps worth it. 

However, that’s almost never the case. Most of the multicloud redundancy that I see backs up systems that are needed, but if they went out for a few hours, the impact on the business would be minimal. Of course, if the argument is that this protects the business from a major outage that we’ve not seen yet, and this type of redundancy helps you sleep better, then go for it.

Another argument for multicloud redundancy is you can never be too careful. Actually, you can. You can “be careful” the business into bankruptcy, if you take things too far. 

You have to consider a realistic business case for pulling off multicloud redundancy for each workload and data set. The cost must be considered in a realistic evaluation that a single provider would actually go away for so long that it would damage the business more than the price tag for deploying multicloud redundancy. Also, you have to factor in the redundancy already existing within a single cloud provider brand, including the ability to leverage physically dispersed regions for intracloud redundancy that you don’t have to set up and operate.

I’m not saying that multicloud redundancy is a bad idea. For those who believe in the additional safety and can justify the cost, go for it. I’m saying that there is a value point to consider for each application and data set, and without doing that math, you’re wasting resources that could be put to better use in other places in the business.