Why Adopt a Multi-Cloud Architecture?

If your service is successful, often your organization can’t afford an outage. Not even a small one. For example, a trading platform will incur heavy losses if it were to go down even for a single minute. In another case, a vehicle fleet tracking system must provide its users up-to-the-moment information and an outage means breaking contractual obligations. Running compute across AZs is a great FIRST step, but it won’t help when a whole region experiences issues. Regardless of cloud, entire region (multiple AZs) failures do occur unfortunately. They happened before and they’ll happen again. Organizations that do not wish to experience outage events must build resiliency across regions, not just across availability zones. This brings me to the topic of “Why multi cloud?”. While whole cloud failures are rare. They can happen. When such an event happens, critical systems are affected.

To deliver 99.999% or higher availability, systems should rely on the combined strength of multiple clouds. In a scenario where AWS experiences a global outage, say Route53 is having a cross-region catastrophic issue, relying on a single cloud spells trouble. Building resiliency into your system so it can survive in the face of a global AWS failure makes sense. Just like an airplane is built with redundancies, so should critical backend apps.

Spreading your microservice deployment across different regions AND clouds makes sense for the following reasons:

• A whole cloud failure doesn’t take your service down
• Some clouds have presence in regions others do not. By being close to your users, their latency is lower
• Sometimes you need to leverage a combination of services from more than one cloud. For example Active Directory from Azure and Aurora from AWS.