Weigh the challenges of multi-cloud disaster recovery

Failure considerations

There's a simple rule of thumb when it comes to the reliability of complex systems: If two elements can perform the same tasks, they can back each other up. This lowers the combined risk of failure. Conversely, if both elements have to be actively working for a complex system to operate correctly, the risk of failure is higher.

So, for two clouds to be more reliable than one, each cloud must be an independent resource pool capable of supporting the applications targeted for backup. This profoundly impacts architectural choices, costs and other factors for organizations that opt for a multi-cloud disaster recovery strategy.

Moreover, you're unlikely to need the type of DR redundancy multi-cloud would offer, since it would be extremely rare for a single failure to take out both your data center and your cloud provider. A simpler way to mitigate risk is to use one cloud for backup, with assignments distributed across availability zones. Enterprises that build a hybrid cloud architecture -- the go-to approach for cloud DR -- can then have their data center and cloud environments back each other up.

Fortunately, application changes and cloud services choices are largely the same whether architects build for hybrid cloud disaster recovery or multi-cloud disaster recovery.

In order to use multi-cloud DR, enterprises need to be able to move workloads seamlessly across boundaries, including across clouds and local data centers. Applications must be built to run anywhere and operations teams need to treat all hosting resources as a single pool. Any limitations to either of these practices reduces multi-cloud disaster recovery benefits and raises costs.

Enterprises also need to consider the two levels of public cloud services and the impact of each on a multi-cloud backup strategy:

• IaaS hosting. The cloud provider offers VMs in various geographic locations with varying resources per VM and different service level agreements. While the cloud providers' operational practices usually differ a bit, it's not complicated to accommodate these differences.
• Web-service-enhanced hosting. Enterprises consume higher-level features via a set of APIs. Typically, applications that use web services will have to be customized for each cloud because of feature and programming differences. This doubles the development burden and may also increase licensing and operations costs.

Containers and microservices

If each cloud is managed separately as part of a multi-cloud plan, it becomes difficult to fail over between environments without human intervention.

You have two choices to alleviate this issue. The first is to forego cloud providers' operations tools. For example, skip managed Kubernetes in favor of a Kubernetes ecosystem run from your data center with tools such as Red Hat OpenShift or VMware vSphere. The other option is to link your cloud provider managed services through a federated approach with tools such as Google Cloud Anthos or IBM's Kabanero.

It's easier to build a multi-cloud-ready application using microservices and a service mesh, such as Istio or Linkerd. However, this approach requires software rebuilds that might be too big of a leap for some organizations. If you do go this route, you'll want to have your service mesh integrated with your operations tools. Service meshes include component discovery that spreads across clouds, as well as workload balancing.

Cost requirements

Enterprises must weigh the cost of multi-cloud DR against the amount of reliability it will add.  Unfortunately, a precise analysis of these factors is nearly impossible because the cost of preparing applications for multi-cloud disaster recovery depends on the number of applications involved and how they're designed.

The costs associated with elastic application deployment and redeployment hinges on these same factors, and your operations practices determine how fast your recovery will respond to problems, which is a big factor in your reliability gains.

Regardless of reliability concerns, hosting costs will certainly go up with multi-cloud DR. There's no value in disaster recovery if your backup resources can't host work shifted from another failed hosting point, so enterprises will have to reserve some capacity in each cloud to support any failover. This can add at least 25% to your cloud hosting costs, and it may even double them if all your applications can tolerate little to no downtime.

The one exception is serverless. Since it follows a pay-per-use pricing model, charges will tend to cost the same for whichever cloud runs your components. But remember, serverless can be a more expensive hosting option, especially for apps that need to run often, and it requires more specialized application design.

Multi-cloud for more than DR

Multi-cloud discovery probably won't pay off for most enterprises, but that doesn't mean it's a bad idea to use multiple clouds. Many enterprises rely on multi-cloud to get effective cloud service positioning for global operations. Some require special features for applications that aren't provided by all cloud providers, so they end up using different clouds for different applications.

Planning for multi-cloud means you're preparing for any-cloud. It's always a smart move to keep your options open, especially as the public cloud provider landscape continues to shift.