Is your cloud provider working today? How good is digital transformation if a cloud service outage cripples your application environment? These questions are on the minds of many tech executives as they wrestle with building a cloud-integrated technology stack to run their enterprises’ most critical processes.
Addressing the problem is not easy, however. Right now, the onus is on the customers to figure out how to make their systems resilient in the face of cloud-based service outages, as there are no formal multivendor cloud agreements in which one provider handles failover for another. As such, many businesses have explored replicating workloads in multiple clouds, which comes with both significant architectural problems as well as high costs. Faced with the expense and technical challenges of multi-cloud resilience, some users find that cloud regions seem to offer a firebreak for most service outages and therefore look at single-cloud, cross-region resilience options instead.
But in reality, could Azure work as a failover for Amazon Web Services (AWS) or Google Cloud Platform (GCP) or some other form of cross-cloud resilience at the provider layer?
I believe the architectural differences between the hyperscalers would limit this possibility technically. Certainly, some services that are compatible have pretty easy ways to deal with cross-cloud conversion, including S3 bucket replication and cloud-to-cloud VM transformation. Yet unlike the power grid -- which has standardized on the voltages, phase, and current provided and provides clear-cut ways to transform power to make sure those electrical characteristics match -- the cloud providers provide different services. Azure Functions is not the same as AWS Lambda. GCP Spanner is not the same as AWS RDS. When you are trying to translate applications at the code or database layer on the fly, too much can go wrong. If a few houses exploded every time the power grid had to pull power from another grid, people wouldn’t call that resilient.
Read the rest of this article on InformationWeek.
