Resilience to Outages
While rare, cloud outages can and have occurred and can be extremely harmful to your business. Outage of even a single service can create a massive domino effect, as demonstrated by the AWS S3 failure back in 2015, which killed or disrupted eight different AWS services, and took down a plethora of other services that depend on those eight primary services. Having a multi-cloud strategy in place, with clearly defined DR (Disaster Recovery) and business continuity protocols that take advantage of the different cloud providers, can help mitigate or completely dodge the destructive effects of cloud outages on your business.
In order to achieve a streamlined multi-cloud deployment, your applications need to be platform-agnostic. They can’t rely on any one provider’s proprietary service or technology, but rather on ubiquitous services that are available with any of the large cloud providers. This essentially means sticking to the basic IaaS. For example, on AWS you will want to stick with EC2, EBS and S3 services, which are bare-bones infrastructure that can be ported to Azure VMs and blobs, but refrain from using services like AWS Lambda. Even though the latter has a parallel service on Azure (Azure Cloud Functions), the two providers have different and proprietary implementations that may not port well.
One of the most complex issues when using a public cloud is billing. Monthly cloud bills are a virtually endless list of hard-to-comprehend line items, services, price rates, and tags. Determining the cost of an application, or the cost to be charged back from a business unit, is tedious and error-prone. This challenge becomes even more complex when multiple cloud bills arrive at the end of the month.
For example, Google Cloud Platform offers on-demand pricing, but applies sustained use discounts automatically. AWS, on the other hand, has Reserved Instance pricing, which, if fully paid upfront, won’t be charged for on a monthly basis. When looking at block storage (instance-attached volumes), AWS charges for I/O operations on their magnetic drives, while Google does not.
To avoid this chaos, it is imperative to use multi-cloud financial management tools when employing a multi-cloud strategy. These tools aim to 'normalize' all the different cloud bills into a single presentation. In addition to clarifying pricing and chargeback, this allows apples-to-apples pricing comparison between cloud providers and lets you choose the best-priced cloud combination for your needs.
In the business world it is never recommended to rely on a sole provider for your operations. The same applies for your cloud provider: operating within a single cloud provider creates many business risks. This lock-in to a single cloud provider also weakens your position when negotiating prices and terms with the cloud provider. Multi-cloud architectures can make sure that you aren’t dependent on a single provider’s technology.
External Business Requirements
Deploying a multi-cloud architecture is not always an internal business decision, but rather a requirement brought in by customers. Some customers have a preference for one cloud provider or another, and, depending on their size and significance to your business, can force you to deploy a dedicated copy of your application on the cloud of their choice.
Walmart, for example, sees Amazon.com as its main competitor in the retail industry. Out of concern for business espionage by Amazon if their data is stored on AWS, it requires all of its software / SaaS suppliers operating on AWS to deploy another copy of their product on a different cloud provider.
Connectivity & Failover
When operating within a single cloud provider, intra-cloud data transfer costs are usually very low (and very often free). This is not the case for data transfer outside the realms of a cloud provider. These transfers carry a significant price tag, and, when working with multiple clouds, the amount of inter-cloud data transfer grows and makes for a hefty sum at the end of the month.
Building reliable systems is a huge, cross-industry challenge today. Although books could be written on this challenge, here are a few rules of thumb:
- Active. Keep all of your clouds running, even at minimal capacity, all of the time, ensuring integrations and data pipelines are in place. Not all your clouds need to be in full scale all the time, but there is a huge difference between scaling up, and starting up.
- Practice failing. Periodically force one cloud to take over for all the rest. This practice will allow you to face, in a controlled setting, the problems you unknowingly created.
- Move your users around between clouds at random to see what new issues they might encounter. It’s best that those issues happen when you have time to help them, and not when you’re dealing with a live crisis.