It is an unfortunate fact of life that things fail. Vehicles, utensils, appliances, even buildings eventually break down in one way or another and something in them stops working. With IT it’s no different. Everyone who has worked in IT for any period of time has experienced some issue related to failures, from hardware – faulty disks, broken PCs, power surges – to software failure – buggy software, application crashes, unhandled exceptions. If anything, the failure of hardware and software seems to be accepted as the norm, rather than the exception, by end-users. Just think about how routine it seems to reboot a laptop, or even a server, if something isn’t working properly.

With cloud computing, it’s no different: even if your cloud provider offers a 100% uptime guarantee for all the services you rely on, these services will eventually fail. You need to be prepared for when they do. While part of being prepared means having redundancy built into your cloud-based application, many times this redundancy is limited to running redundant copies of your application on separate data centers of the same cloud provider. While this is recommended – it is, after all, one of the reasons why all the large providers have multiple data centers in separate geographical locations – another possible strategy is adopting multiple cloud providers.

Reducing risks

By adopting a multi-cloud strategy, that is, by running your cloud-based deployments on multiple cloud providers, redundancy is taken to a whole new level. By selecting data centers from different providers to host our cloud servers, we can effectively eliminate the risk associated with the business continuity of the infrastructure provider, as well as risks related to electricity suppliers, networking providers and other “data center” issues, since each cloud provider will usually operate separately.

A multi-cloud strategy also reduces other risks associated with having a single provider: let’s say someone discovers a vulnerability on the virtualization platform that your current infrastructure provider uses. If you are deploying on multiple clouds, you can simply shut down the servers on the vulnerable provider with little or no impact to your operations. The same mentality applies if suddenly your provider decides to increase its prices, or even change its terms of service: shut down your servers, and move your business to someone else.

Virtual power

For a while, during the early years of cloud computing (which was no more than 3-4 years ago), adopting a multi-cloud strategy was hard. Cloud providers operated on proprietary closed architectures that made migration a headache: you’d need to effectively download whatever data you had, rebuild your virtual machine from scratch on another provider, and then upload everything back again. Today, however, these barriers to change are dropping fast.

Motivated by the need to enable the interoperability of existing corporate data centers with their own public infrastructure, cloud providers are facilitating the upload and download of entire virtual machines, so that copying your VMs from one provider to another is easier than ever. There are data migration solutions that allow you to move data from one service provider to another with ease. There are even cloud-based service providers, such as Cloudability, that make it easier for you to manage multiple cloud providers at the same time.

Like what happens in any market where competition abounds, on the cloud there are significant differences between providers: some will offer better support, some will offer better SLA terms, some will have lower prices, some will have better APIs and so on. The best way to understand these differences and choose the providers that best fit your needs is to experiment with them. I spent a good six months experimenting with different infrastructure providers before settling on the ones (three at any given time) I currently use, and I’m always evaluating new alternatives. With the tools and functionality available today, there is no excuse for not going the multi-cloud route.