‘Spreading the risk’ using multicloud

Recently the banking industry has faced questions about its use of cloud computing. There is concern that concentrating on a single cloud provider’s resources could leave that bank exposed if the cloud provider has a major outage or for some other reasons goes away. Or more likely, jacks up prices to unacceptable levels or changes to draconian terms.

There is even concern that regulators won’t be able to access information from some public cloud providers, many of which are hosted in other countries. The concentration of compute and storage resources on platforms not owned and operated by the banks could lead to unacceptable risk to bank customers, investors, and other stakeholders. There are many dimensions to these risks.

If a client told me that they were going with a single public cloud provider, my concern would not be risk of lock-in with that provider in terms of outages, price gouging, or even going out of business. It would be more about limiting themselves to solutions found in the “walled garden” of a single cloud provider. In other words, not being able to leverage the best solutions across cloud providers and ending up with an underoptimized architecture.

The question here is not about creating the best and most optimized solutions, but spreading the risk by using a true multicloud deployment, meaning two or more public clouds. Although I think this is less important than finding the best technology to solve problems, there is something there to explore as well.

Multicloud has much disaster recovery value. Many innovative enterprises have leveraged one cloud provider as the primary system host and another as a secondary. For the same application and data this means that the system can fail-over from one provider to another, in many cases without the end users even knowing that the back-end cloud provider has been swapped out automatically. This an active-active approach to disaster recovery.

If you think active-active is expensive to build, deploy, and operate, you are correct. You can count on twice the cost of deploying the same application and data on a single cloud provider. This is why we still don’t see many of these types of multicloud tricks, but they are out there. 

More important is the value of having options. Multicloud gives you the choice to find best-of-breed technologies among three to five public cloud providers versus a single one. More options lead to reduced systemic risk as well, which I think is of secondary value and consideration, but it’s indeed a value of multicloud, nonetheless.

I recommend that those leveraging multicloud create playbooks that define how applications and data can be migrated to another cloud provider within the same multicloud deployment, either in reaction to unacceptable increases in prices, excessive outages, or a concern with the business itself.

This requires that you have staff who understand each cloud provider and are able to leverage existing in-house resources to make the move rapidly. If you’re not using a multicloud deployment, your response will take months or even years versus weeks to leverage a new public cloud option within a multicloud deployment. If you’ve already got a multicloud arrangement, the operations, security, and governance layers will already be in place, and moving from one cloud to another will be easy.

Not concentrating most of your applications and data on a single cloud is a clear multicloud value. This may be why people adopt multicloud—as a way to mitigate risk. However, I think other features are of greater value.