There are good reasons for spreading workloads and applications across multiple clouds. Options include using a combination of public and on-premises cloud platforms, a strategy known as hybrid cloud—or using more than one public cloud provider, a strategy known as multi-cloud.

What are those benefits? And what are some of the best strategies for achieving them?

Let’s explore that. (And for the purposes of this post, I will use the term multi-cloud to denote both multi-cloud and hybrid cloud options.)

Multi-Cloud Benefits

Let’s start with multi-cloud benefits. These fall into five categories:

Risk management. Considering the significant failures that we’ve seen in public cloud providers over the last year, this is becoming increasingly important. A multi-cloud approach helps us alleviate risk by giving us the ability to easily scale across these clouds. 

Regulation. Some risk management concerns are driven by privacy and data sovereignty regulation. Organizations are required to store data in a way that conforms to sovereignty and privacy rules and this may limit options geographically. For example, European regulations prohibit European data from being stored on U.S.-based servers.  

Location. Low latency is critical for some applications, and the world is moving rapidly toward edge computing to minimize the distance between the cloud and the user. Location also impacts costs. 

Sometimes cloud storage is expensive, and it may be more economical to store some data locally. Ideally, I would like to be able to pick the locations where I run my workload and where I store my data. 

Leverage. If I’m able to leverage multiple public cloud providers, I’m not locked into any one of them. Perhaps one provider has a better artificial intelligence offering and another has a better analytics service. I’d like to be able to pick which of those I prefer and still run my own applications and workloads effectively across those environments. 

Price/efficiency. The ability to access multiple public clouds gives you the ability to continually optimize the cost and/or performance of your applications. 

Multi-Cloud Use Cases

There are four key multi-cloud use cases: 

Cost optimization. This relies on being able to move workloads from one public cloud provider to another or from a cloud provider to data center hardware that I already have inside my company. It also may save costs to use different cloud providers in different parts of the world.

Regionality. This involves putting your workloads where they need to be, which increasingly is at the edge as local processing becomes more important. Regionality also may involve data sovereignty, as we discussed earlier.

Disaster mitigation. We’ve been talking to customers who have gone all-in on a public cloud and have either suffered from failures or have governance reasons within their business to have a backup from a different provider. 

Scaling or bursting. This primarily involves companies with seasonal expansion of workloads, such as retailers during Black Friday or the Christmas season. It would be crazy for them to provision for the transaction volume they see at peak times for the whole year. 

Another example is when a company has invested heavily in premises-based solutions that work well, but the investment is maturing. When the company needs a little extra capacity, it doesn’t make sense to build it locally. 

Multi-Cloud Challenges

It’s important to recognize the challenges of a multi-cloud strategy, as well as the benefits. 

There are four key challenges:

Greater initial effort. A multi-cloud strategy requires a lot of planning. Because you are dealing with different providers, you’re dealing with different systems, APIs, costing models and levels of complexity. This means that we need to think in more detail upfront because making all sorts of adjustments later can be painful. 

Increased complexity. It’s easy to use a single cloud that already has been pre-integrated. It’s harder to do it over multiple providers. The complexity comes in needing specific tools for data replication across dissimilar systems. 

It comes in having to manage all these different services, whether it’s Google Cloud Platform, Amazon Elastic Compute Cloud, Amazon Elastic Kubernetes Service or Azure Kubernetes Service. 

How do I get some level of consistency across all of these? And how do I build in that management layer to simplify this experience? If it’s too difficult for the developers, they’re not going to use it, and you’re going to lose your multi-cloud value.

Networking and latency. These are two interrelated challenges. It’s great that we can stretch a cluster across two clouds, but what happens when the latency between the two clouds starts to shoot up because an internet connection is overloaded? You’re going to get weird performance in applications. 

We need the right tools and systems in place to handle and manage that connectivity effectively, localizing data but still providing the correct cross-site communications. You also must determine how to abstract the complexity of different IP address ranges, whether it’s IPv4 or IPv6, and whether there are different security models for egress and ingress.

Add-on service usage. Public cloud providers are giving us databases and analytics tools and extra security tools. And of course, every cloud has a different set of tools. If I build applications that rely on something that Amazon offers versus something that uses my on-premises database, it’s not exactly portable. 

The upshot is that you must examine the use of those add-on services carefully and think about the rules you’re putting in place to guide your developers to make the right decisions. (Notice I said “guide” the developers, not dictate to developers because the latter approach is rarely successful.)

How Do You Make It Work?

There are six key elements that go into making a multi-cloud strategy work:

Ease of Use. If it’s too complex for developers to deploy applications into the multi-cloud environment, the developers will look for a shorter path to getting their applications up and running – and that’s probably going to be direct to a single cloud provider. We need to really abstract the complexity. 

Consistency. We need a consistent platform across all these environments. We need to have the operational automation set up correctly so that I have consistent security, policies and identity management across all these systems. Also, applications must be deployed via continuous integration/continuous delivery (CI/CD), with no manual deployments. 

More Than Kubernetes. Kubernetes is more than just a container orchestration system. There are many different layers that we must consider—identity, role-based access control (RBAC) and service mesh capabilities. How am I linking all these systems together? 

We must recognize that the container orchestration layer and the container layer are just a small part of the overall solution. We must think about how we orchestrate all those extra capabilities on top of that.

Centralized Control. This won’t be popular with everyone, but we want a central—or more precisely, federated—way of pushing policy, assigning RBAC rules, assigning identity management and deploying applications. The solution needs to be resilient and capable of using different systems underneath and provide the flexibility for us to choose how we use these different systems.

Freedom of Choice. We need to provide the flexibility to choose the provider and tools that are necessary at all layers of the stack. What CI/CD tool do I choose as a developer? What security tools are most appropriate for the application? 

Centralized Monitoring. Having a centralized view of all your systems is critical.

Multi-Cloud Means Consistency and Connectivity

A multi-cloud solution requires an effective way to manage the infrastructure and provide effective connectivity between systems and data. We need a clear multi-cloud management tool that can stretch across all the clouds and provide the correct layer of abstractions so that we don’t have to deal with all the different APIs in our CI/CD. 

Our CI/CD must be usable. Some CI/CD offerings handle multi-cloud, but not very well, so if possible, we should address multi-cloud issues in a multi-cloud management API. We need effective and consistent security across all these systems, ideally from the multi-cloud management tool so that we have a single pane of glass to view and manage everything. 

We need an effective service mesh solution to handle networking.

Lifecycle management of all these different components needs to be integrated. It would be a nightmare to have a lifecycle management system handle an operating system upgrade completely on its own without considering the workload on top. We must have the ability to effectively update components with some awareness of what individual applications are doing.

Our multi-cloud management system also should enable freedom of choice.

Finally, it’s important to have the right partners. There are a lot of very smart eggheads out there who we can leverage to do things in the right way—smart tools and smart partners so that we can layer up an effective solution. 

At Mirantis, we are building tools to enable multi-cloud applications. We would love to hear how we can help you and what we can do to make this process easier.