All about Multi Cloud

Excuse me. Your cloud is broken.

 

Do your applications still work when your cloud breaks?

The recent news of a popular cloud provider suffering an outage that affected a broad swath of their customers, again, brings to mind the risks associated with a single-cloud approach.

In a future blog post, I will cover what I believe, to be the key differences in the approaches that make up the multi-cloud strata, but for now let’s focus on application availability and the idea of the multi-cloud.

 

Application availability and the multi-cloud

Today, applications are built from an array of micro-services deployed in the form of containers and into “the cloud”. When we invoke the idea of the multi-cloud, the most common scenario is to present a common orchestration framework (like Kubernetes or Terraform) with connectivity to multiple cloud service providers. When an end user decides to deploy that application, they choose which cloud they would like to deploy their microservices into and away it goes.

Fig 1. Traditional multi-cloud architectures are flexible at the point of consumption, but still siloed.

The application is deployed into the cloud service provider of choice and day 1 operations begin. Unfortunately, in this particular multi-cloud model, the application is still siloed, meaning that any outage that affects the cloud service provider will cascade up the stack eventually affecting the end-users. Outages like these can affect have broad and long-lasting effects*.

To the multi-cloud…and beyond

The ideal multi-cloud scenario would allow micro-services from the same application to be deployed across disparate cloud service platforms. Deploying micro-services in this way would limit the impact of a platform outage to just the components of the application that were deployed onto that platform.

Fig 2. Multi-cloud deployment across disparate clouds limits how much of the application is affected during an outage.

Affected containers can be re-deployed onto the unaffected cloud platforms, minimizing the effects of the outage and consequently minimizing any losses for the organization as well.

I know what you’re saying. You’re saying “That sounds great. But what about stateful data?”. Well that’s where a highly available persistent storage fabric comes in.

Fig 3. Using a highly-available persistent storage fabric across cloud service providers allows stateful container volumes to be snapshotted and replicated from their respective source clouds to any destination cloud.

A storage fabric such as this would allow persistent volumes to be replicated across clouds providing a level of application resiliency that doesn’t exist today. Layering this approach with modern clustered application methodologies provides true multi-cloud application availability.

Luckily for you…I know just where you can get a data fabric like this ;-)**

 

*In the last year, all 3 of the major cloud service providers suffered service outages that affected end-users and resulted in financial losses for customers.

https://www.zdnet.com/article/microsoft-south-central-u-s-datacenter-outage-takes-down-a-number-of-cloud-services/

https://www.theregister.co.uk/2018/06/01/aws_outage/

https://status.cloud.google.com/incident/cloud-networking/18012

 

** HTBASE JUKE is a multi-cloud control and data fabric that pools disparate cloud resources together so that they can be managed and integrated into a container orchestration platform as a single locally addressable entity. JUKEFS allows snapshotting and replication of persistent container volumes across multiple clouds. For more information, contact us at contact@htbase.com