In 2019, Gartner predicted that by 2021 up to 75% of large and midsize organizations would be running some variation of multicloud environments. This IT trend is due in part to the modern necessity of working on multiple cloud platforms, and in part because it’s easy to do—though your cloud architects and DevOps engineers may not agree.
Possibly the most painful part about adopting a multicloud strategy is connecting your public cloud providers to each other. If that newly designed multicloud setup also connects to your on-premise workloads, it can be even harder to implement and maintain. But these challenges don’t have to stand in your way.
In this two-part series on multicloud networking, I’ll demystify the process of developing a multicloud strategy. For our first installment I’ll go over theories and concepts, while part two will provide practical examples of connecting AWS and GCP.
Pros and Cons of a Multicloud Strategy
The following list of benefits—and even a few drawbacks—are important elements to consider before implementing a multicloud strategy.
Benefits
The most obvious benefits of multicloud adoption are increased fault tolerance and the elimination of vendor lock-in, but there are a number of other reasons as well.
Eliminating Vendor Lock-In
By running workloads on at least two public cloud platforms, you aren’t limiting yourself to the services that one provider offers. This means that as your cloud architects develop their environments they have the freedom to consider:
- A given provider’s features
- The complexity of using services from multiple providers
- The costs associated with using multiple providers
High Availability
Because it’s unlikely that two major public cloud providers would have outages at the same time, deploying across providers can ensure your enterprise maintains high availability.
For example, in 2017, the AWS S3 service went down in the us-east-1 region. The companies running only in AWS would have been able to maintain service if they’d had failover deployments on Azure or GCP, since both Google and Microsoft have their data centers in North Virginia where the AWS us-east-1 region is located.
Managed Services
Enterprises often overlook managed services and decide to provision their own, self-hosted solutions instead of opting in for the SaaS workloads. This may create a burden for their engineering teams, and might even result in added costs. If a public cloud provider doesn’t offer a managed service tailored to your needs, going multicloud will allow you to utilize a competitor’s services instead of trying to go it alone.
Amazon, for example, has a managed MongoDB database service called DocumentDB, managed Prometheus and Grafana monitoring offerings that require no work to set up, and managed messaging services like Kafka, ActiveMQ, or RabbitMQ.
Azure and GCP don’t have those listed services, other than Azure Service Bus which has support for ActiveMQ. This means that if your primary cloud provider is Azure or GCP, you may turn to AWS for these kinds of features.
Drawbacks
Despite their many advantages, multicloud strategies are not without drawbacks.
The primary disadvantage of working across cloud providers is the complexity of designing, deploying, and maintaining effective multicloud environments. Public cloud providers make an effort to ease this burden by sharing some concepts—like the shared responsibility model, assisting with the abstraction of hardware, and offering similar pricing models. But the setup of core multicloud functionalities, such as networking, can be cumbersome even for experienced IT veterans and network engineers.
Before I dive into multicloud networking examples, I’ll illustrate the fundamentals of this pillar of multicloud adoption and highlight the main services available in all three major public cloud providers.
Are you a tech blogger?
What Is Multicloud Networking?
Multicloud networking connects on-premise workloads with at least two public cloud providers to create a mesh network topology.
In hybrid cloud topologies, your cloud architects and network engineers have the goal of connecting your on-premise IT infrastructure with a public cloud provider. That infrastructure can range from a group of servers and network firewall or router devices in your office to a full-fledged datacenter environment. With multicloud networking, this becomes exponentially more complex.
In essence, multicloud networking is a level of complexity above hybrid-cloud networking. This is because it requires you to connect two or more public cloud networks to your on-premise network in addition to connecting your public cloud networks to each other.
A Multicloud Use Case
How does a multi-cloud networking setup look in the environments of big enterprises? Let’s take a look at a real-world example.
Let’s say that you’ve been running on-premise workloads in your datacenter. You’ve connected it to AWS to extend your on-premise workloads with services such as S3, RDS, DynamoDB, or other managed offerings. Now your team of system administrators want to extend the internal Active Directory environment with Azure AD, and to migrate internal Exchange servers to Office 365. Their goal is to streamline email services and offload operational and management tasks to Microsoft.
To successfully introduce Azure into your global enterprise networking topology, you would need to include another networking site for Azure, and two more connected network endpoints: AWS to Azure, and your on-premise datacenter network to Azure.
In the end, you will have three isolated network segments (AWS, Azure, and your datacenter) each of these will require a /16 subnet mask, or smaller, if you have the need for more network hosts. You will also have three links connecting these segments (datacenter to AWS and Azure, respectively, and from AWS to Azure).
This change would involve even more complexity and configuration, but luckily you can reuse the networking concepts and protocols you’ve already been using in your hybrid deployments. For encryption of the network tunnels between public clouds and your datacenter, you will probably rely on a IPSec/IKEv2 comb, with your own or PKI infrastructure from the public cloud providers. When it comes to routing, the most logical choices are either to use static routes or BGP for dynamic propagation. However, EIGRP and OSPF are also supported if you deploy cloud-hosted routers that support these vendor-specific routing protocols.
Additional options, beyond IPSec tunneling, include:
- MPLS
- VPLS
- VXLAN
- L2TPv3
Other options are available, but the best fit for your needs will depend on what equipment you have on-premise, how you decide to connect your clouds and datacenter, and if you use collocation peering. All the major public cloud providers offer collocation through their services and partners and we’ll explore those options in greater detail in the next section.
Necessary Services for Multicloud Networking
When it comes to cloud networking concepts, AWS paved the way for other public cloud providers. Public cloud networks introduced the idea of abstracting firewalls and routing networking devices into a unified configuration that can be performed through a variety of methods, including:
- Web console
- SDK
- Command line interface
- A variety of third-party, open-source, or commercial tools
Regardless of which provider you use, you’ll need to provision many of the same services:
- VPC: VPC, or virtual private cloud, is an isolated network segment in which you provision subnets and access control lists.
- Subnets: VCPs are segmented into subnetworks which you decide to make either public (available outside of your VPC, from public internet) or private (only visible inside the VPC).
- Gateways: This includes an internet gateway for internet access, a network address translation (NAT) gateway to allow hosts in private subnets to have outbound connections to internet (for example, if you need to patch your servers), or VPN gateways (for establishing VPN site-to-site connections with other public clouds or your on-premise environments).
- ACLs / firewall rules / security groups: The cloud is already abstracting your firewall devices, but you still need to specify some rules or access control lists with which to control traffic in your VPC. These rules can be defined on the subnet or host level, depending on the service and public cloud provider you use.
- DNS: You will need to rely on cloud-managed DNS services to make internal DNS queries resolve between all interconnected networking sites.
- Private (direct connectivity): This is the only network segment that is not standardized between cloud providers. AWS, Azure, and GCP all have separate services, vendors, and partners that directly connect your collocated on-premise network environment to their cloud via private, dedicated network connections.
The following table shows the main network services from each of the major public cloud providers:
Service | Amazon Web Services | Microsoft Azure | Google Cloud Platform |
Virtual Networking | |||
VPN | |||
Private connectivity | |||
DNS |
Table 1: Common network services offered by the Big 3 cloud providers
Summary
You’re now familiar with the most important concepts behind multicloud architecture—especially multicloud networking and the differences between the most essential cloud network services from Amazon, Microsoft, and Google. In the second part of this series, I’ll cover the basics of connecting enterprise-grade AWS and GCP multicloud environments.
(Don’t miss Part II in this series on Multicloud Networking Deep Dive)
