How Many Clouds Do I Need? Selecting Multi-Cloud Vendors in the Real World

When deciding to move an application to the cloud, you need to consider many factors before choosing a cloud provider. What features do you need? Which cloud is faster? Which one is cheaper? Which one is more reliable?

But here’s another question that is being asked more and more often: How many cloud providers should you use?

Why on earth would the answer be more than one?

As it turns out, cloud customers cite a number of reasons to use multiple cloud providers. Some useful features might be available from one provider while others are available only from another provider. You might find it easier to negotiate price and performance with one vendor when you also have a relationship with another vendor. Or you might decide that having multiple providers gives you higher reliability than depending on a single provider.

That said, using multiple cloud providers may or may not be right for your application or your company. Let’s take a look at what goes into making the best decision for your situation.

Defining multiple clouds

Before we get there, though, we need to create some definitions. The actual set of advantages and disadvantages of a multi-cloud arrangement depends greatly on the type of multi-cloud environment you are considering. So let’s look at three different types of cloud configurations: joint cloud applications, selective cloud applications, and single cloud applications.

1. Joint cloud applications

This is when a single application uses two or more cloud providers to provide parallel capabilities. A given application or its services can run on any or all of the supported cloud providers, as shown here:

App1 or App2 can be run on either of the cloud providers, and can be load balanced between them if desired.

Each application must be designed to run on either cloud provider, and the application can use either available provider to satisfy a given request. If one provider is unavailable, the other provider can take over to process requests for the application.

The main advantage of this approach is application resiliency. If a cloud provider experiences an issue, the application workload can be rerouted to the other cloud provider easily and relatively quickly. This lets the application continue functioning even if one provider has a massive failure.

This architecture is often cited as a solution to single-vendor cloud lock in. However, it also has significant disadvantages. For example, each development and operations team supporting the application must have knowledge about the workings of multiple cloud providers. This knowledge and understanding does not come for free. Similarly, each application must be tested and maintained on multiple cloud providers.

Additionally, when applications are written to support multiple cloud providers, they cannot take advantage of deeper feature capabilities provided by one particular provider. The application must be written to use the least common capabilities inherent in all the cloud providers being utilized. Finally, applications tend to be more complex when they are designed to work across multiple cloud providers, which can lead to an increase in errors and other problems.

In most cases, the shortcomings of this approach outweigh the perceived improvements in resiliency.

2. Selective cloud applications

This is when your company maintains relationships with multiple cloud providers, but any given application runs entirely on a single provider, as shown below:

You can see that each application is hosted on only a single cloud provider, but different applications may be hosted on different cloud providers.

In this scenario, a given component is designed and capable of running only in that single provider’s cloud. If that cloud provider becomes unavailable, then the application will stop running. You cannot simply move traffic over to an alternate cloud provider. This is typically more of an intellectual issue than a practical issue. It is rare for an entire cloud provider to become unavailable. Typically, only one or more availability zones or regions become unavailable. A properly written application can take advantage of multiple availability zones and regions to improve application resiliency without having to resort to using multiple cloud providers.

However, individual applications or services can independently select which cloud provider they want to use, based on whatever criteria makes sense for that application or service.

This architecture requires that each individual development and operations team supporting a given application has to learn and understand only how the single cloud provider they work with operates. Additionally, each team can take advantage of deeper feature capabilities unique to their specific cloud provider. The applications themselves can be designed, built, and optimized using cloud provider-specific best practices. In addition, the company as a whole has knowledge about multiple vendors, making evaluating cloud vendors a more data-driven endeavor.

However, in this architecture the company must maintain multiple vendor relationships and agreements with each supported cloud provider. And, as noted, if a cloud provider has a serious outage, the applications running on that particular cloud provider may become unavailable.

In most cases, this approach gives you the desired flexibility of multiple clouds and the ability to do deep integrations with your cloud providers, without the application-level complexity that joint cloud applications require and without significantly sacrificing application resiliency.

3. Single cloud applications

This is the simplest design, in which a single cloud provider is used for all cloud needs within the company, as shown here:

In this architecture, the company standardizes on a single cloud provider. It allows all development and operations teams to focus on the capabilities of that one provider. Knowledge can be easily shared across teams, and multiple teams can leverage a single set of best practices. And all applications can take advantage of the provider’s full set of features.

From a management perspective, having a single cloud provider simplifies vendor management. Higher volume usage may allow you to negotiate better pricing and other terms. Finally, moving all cloud resources through a single vendor may allow for more predictable cost controls.

However, this solution obviously requires a strong commitment to a single cloud provider, which can be problematic for some companies. When a problem does occur, it is much harder to negotiate a solution when you are locked into a single vendor.

This solution may be the simplest to manage and control of all the options, but limits the flexibility of your development teams.

So, which cloud model should you use?

Which cloud model makes the most sense for your company? The final answer depends on the needs of your company and your applications.

From an application perspective, the advantages of having an application runnable on multiple cloud providers is typically outweighed by the cost and complexity associated with maintaining multi-cloud capable applications.

If you are worried about maintaining high availability within your applications while tying them to a single vendor, consider using the high-availability solutions available from that vendor. For example, simply using multiple availability zones and multiple regions for your application running on AWS can dramatically improve your application’s resiliency without incurring the costs and reduced capabilities of making your application run on multiple independent cloud providers.

When selecting a cloud provider, you should look at

• History of reliability. How reliable has the service been historically? How fast are outages dealt with? Do outages impact the entire provider, or just specific regions at a time (allowing you to use multiple regions to improve resiliency)?
• Capabilities of availability technologies. Does the provider give you multiple availability zones and multiple independent geographic regions to allow fault isolation and failover? How independent are the zones and regions?
• Availability of services. Does the cloud provider have the types and depth of services you require?
• Reason for moving to the cloud. Why are you looking to move to the cloud? Is it to accelerate innovation or to help you in scaling? Whatever the reason, make sure your reasons match the cloud provider’s capabilities.

Whatever you decide, don’t assume you must use multiple cloud providers to get the resiliency and flexibility you require. And even if you do decide to support multiple clouds, don’t automatically assume that each of your applications must run on all of them.

Finally, no matter how many clouds you choose to use, it’s critical to make cloud-based application and infrastructure monitoring a part of your strategy from the very beginning.

For more information on multi-cloud monitoring, check out these resources:

• AWS Performance Monitoring
• What It Really Takes to Monitor Cloud Apps and Infrastructure
• 7 Requirements for Monitoring Cloud Apps and Infrastructure
• Successful Cloud Migration in 3 Easy Steps
• Migrate Wisely With New Relic