What is multi-cloud?

Multi-cloud refers to the use of multiple public cloud services providers (CSPs) by an organization to run its business applications. Ideally, the multiple clouds would be under a single or common administration to host compute, storage, application, database, and other services.

Can an environment be multi-cloud and hybrid cloud at the same time?

Yes. If the organization has an on-premises data center and is also leveraging multiple public clouds, it will be considered as hybrid multi-loud.

Similarities between multi-cloud and hybrid cloud models

In both multi-cloud and hybrid cloud scenarios, applications that have dependencies on each other are hosted in different locations. In both cases, enterprises require resilient, performant, and secure connectivity between the hosting sites.

Differences between multi-cloud and hybrid cloud models

There are several differences between multi-cloud and hybrid cloud from an architecture approach, infrastructure requirement, operational model, and application perspectives. 

Being multi-cloud means leveraging multiple CSPs, and these will come with differing features and functionalities. However, all CSPs will adhere to the same principles of agility, performance, features, and scale.

Architecturally, multi-cloud is built with dynamic scale and workloads in mind. Networks and applications must be deployable at elastic scale in a very short amount of time, leveraging automation and cloud scale. The underlay infrastructure is provided by public cloud providers, hence applications can be placed based on the location, performance, feature, and functionality requirements. The operational model in multi-cloud is much faster and dynamic compared to on-premises.

In the hybrid cloud model, part of the applications are still running in on-premises data centers, which means that there are always hardware constraints and software licensing dependencies. The scale is limited to what the organization has pre-purchased and pre-provisioned. Often, organizations run in hybrid cloud models for a long period of time while migrating their applications to the cloud, and there is continued dependency between applications running in different locations.

Why use multi-cloud?

All public cloud providers are continuously enhancing their offerings for organizations to run and host their applications and services. In addition, different cloud providers also have their specialties, for example, one cloud provider may provide excellent AD, email, and compute services, another may have excellent databases, and another may be great at ML and AI services. 

In an enterprise, the choice of public cloud is often not driven by the cloud itself, but instead it is driven by where the application runs the best. Mostly, the application placement decision is not made by a single entity; instead, different teams make their own choices, depending on the features and functionalities required. In addition, familiarity with the platforms may also result in the use of multiple public clouds. 

Lastly, the use of multiple public clouds can result from business activities such as better terms from different public cloud providers; mergers and acquisitions where the other company is already using a different cloud provider; competitive businesses run by the cloud provider, etc. 

How does multi-cloud work?

Multi-cloud is not used to run the same application stretched across multiple clouds. As mentioned above, applications are placed where they run best. However, this may mean that there may be dependencies between these applications. For example, applications running in Cloud A may need access to some data that lives in Cloud B.

To make multi-cloud work flawlessly, consistent network and security architecture is the most important ingredient. Organizations that deploy a single networking stack that works consistently across multiple CSPs enable themselves to consume the best-of-breed applications from all the cloud providers. When a multi-cloud organization is working correctly, the applications should not have to do anything different to access each other whether they are in a single cloud or multiple clouds. In addition, the Day 2 operations teams supporting the multi-cloud deployment should have a consistent and repeatable approach and toolset irrespective of the cloud.

Examples of multi-clouds

In the following example, a customer is migrating their Oracle Exadata Database from on-premises to cloud. The enterprise applications will be deployed in Azure and multi-cloud connectivity will be built leveraging the OCI-Azure interconnect.

In the following example, the customer is hosting Windows Virtual Desktop and Shared Services in Microsoft Azure and the production and development environments are mostly hosted in AWS.

In the following generic example, an organization may be hosting applications across AWS, Azure, and Google Cloud Platform. 

Multi-cloud connectivity providers and pros and cons of their approaches

There are three common approaches to multi-cloud connectivity providers.

One approach is to leverage on-prem companies such as Equinix, Megaport, AT&T, and Verizon who focus on providing connectivity to the cloud. They do not provide any features inside the cloud, rather, they focus on getting you “to the cloud”. You achieve multi-cloud by managing the cloud networking yourself and routing the traffic destined to multi-cloud to this on-prem connectivity provider. They will then route the traffic to the other cloud. 

The challenge with this approach is that the organization owns the complexity in the cloud and the provider is just an underlay provider. The enterprise needs to equip itself with the tools and staff to DIY in the cloud and deal with a blackbox between the cloud, as it is managed by a different control and data plane.

Another approach is a cloud exchange approach where you build connectivity from your cloud entities to an external location hosted by the vendor. Most SASE vendors fall into this category, including Palo Alto Networks Prisma Cloud, Zscaler, Netskope, etc. These vendors host their services in specific regions of specific clouds and require customers to own and manage their own cloud environments. In addition, when traffic is traversing between clouds, it has to leave the customer cloud/region and go to wherever the hosted services are. 

The benefit of this approach is that customers can get a centralized security stack, but downsides include complex cloud route management, building connectivity to external exchange, limited bandwidth, lack of visibility, and added latency.

The final approach, which Aviatrix customers use, gives enterprises the choice of using internet or private on-prem connectivity to go between clouds. Aviatrix owns and manages the cloud networking in the cloud and simplifies connectivity to the on-premises.

Customers can deploy security services stacks in their own cloud or can connect to an external provider for a specific workload.

Aviatrix is born in the cloud and for the cloud. Schedule a demo to learn why 500+ customers use Aviatrix to solve their cloud networking challenges!