How to Think About Multi-Cloud
Sunday, March 12, 2017
Public clouds are no longer equivalent. These are platforms with some overlapping basic capabilities and yet different in many respects. Here are a few factors I would consider when thinking of multiple clouds.
- Multi-cloud is not a resiliency play. It’s not necessarily going to shield you from any particular provider having a bad day. Any tech company undergoing rapid rate of change is going to have bad days. Recent s3 outage did prompt some questions in some online and offline conversations, and multi-cloud is not the answer to survive such incidents. Design for fault domains and fault isolation, and practice chaos engineering instead.
- Don’t worry too much about lock-in at this time. The differences between public clouds are significant. The value of any public cloud is in the platform aspects and not the basic primitives. Abstractions to prevent lock-in introduce operational complexity and limit you to common denominator primitives like virtual machines.
- A better strategy may be to use different providers for different types of workloads based on suitability of the provider’s platform capabilities for that workload. I would also keep any cross-provider data exchange asynchronous.
- Above all, maintain fault domain boundaries. When you scatter your critical workloads across multiple providers’ regions, you might end up with large fault domains across those regions. This can make reasoning about resiliency hard and lead to longer times to recover. For instance, I would not put the front-end in one provider’s region, and the back-end in another provider’s region except when availability of that application is not critical.
The same considerations apply for hybrid-cloud too.