Here is a challenge. How do you connect the simplest version of a secure public cloud environment that exercises an organization’s muscles, demonstrates the viability of cloud services, and engages all necessary stakeholders?
Some might recognize this description as the methodology for our Minimum Viable Cloud (MVC). The simplest way to connect resources in such an environment has been through a hub-and-spoke network – using peering technologies to exchange traffic over separate networks. The wheel-like design replicates data center functions by providing low-latency access to remote services in these networks through, for example, Active Directory (AD), the Domain Name System (DNS), security and firewall devices, logging and monitoring, build servers, and bastion hosts.
The hub-and-spoke model used to be the simplest and most direct way to connect resources. When banks and other large enterprises started using the cloud to build Infrastructure as a Service (IaaS)based workloads in a single region, the hub-and-spoke network worked crisply and efficiently. Now that more organizations are building cloud-native applications and deploying to multi-cloud environments, network management is becoming too complex for the traditional hub-and-spoke model, with connectivity between spokes managed by network peering.
Taking a closer look at scaled out network patterns indicates some of the potential issues that would develop. If you start building microservices with four applications hosted on different networks that all need to talk to each other, you will need to create connections between all of them, creating a tangled web with no centralized management. With no single pane of glass that looks into all the networks, it is cumbersome to troubleshoot connectivity issues. Therefore, the traditional hub-and-spoke connectivity model needs to evolve from a peering based approach to a more transitive one.
Figure 1: A tangled hub-and-spoke’ configuration
Moving to Transit Gateways
This new model scraps the traditional shared services networking and peering connections, and puts a smart new box called the transit gateway in the middle of the network. The transit gateway connects to the customer network, shared services and all the spokes in the network, providing that centralized management structure that modern cloud environments need. Transit gateways are relatively new. AWS released its own version several months ago that can attach to each gateway up to 5,000 Amazon Virtual Private Clouds (VPCs). Each attachment can handle up to 50 Gbits/second of bursty traffic. There are also a number of third-party solutions on the market, including Cisco CSR, Aviatrix and VMware NSX. These let you manage routing on a grand scale, clearing the way for a more efficient brand of multi-cloud networking.
Figure 2: A single-cloud configuration using a transit gateway
Enterprises that require multi-cloud networking typically deploy Layer 2 or Layer 3 switches on cloud exchanges in colocation facilities close to cloud regions. They route the traffic through direct cloud connectivity services, such as AWS Direct Connect or Azure ExpressRoute.
But with the rise of transit gateways, you can simplify the connectivity between cloud providers. For example, the Aviatrix gateway enables software defined, encrypted IPSec tunnel connections directly between different cloud provider networks without going through cloud exchanges or Multiprotocol Label Switching (MPLS) circuits.
Connecting two cloud environments helps organizations create application portability. For instance, if you are building a point of sale application that cannot allow any downtime, you can port all of your workloads over to Azure if AWS goes down, or vice versa. If you are building an application that requires network connectivity across multiple cloud providers, you can do that, or you can pick and choose which service you want, rather than get locked into one cloud provider.
Value in Staying Old-School
Is there still some value in managing MVC connections using the old configuration model? Sometimes there is.
You have to look at it on a case-by-case basis. If you already have an established VNet peering setup across networks, or if you have already implemented a transit VPC using Cisco CSR, etc., it might require significant effort and downtime to switch over to transit gateway solutions.
If you are a medium-sized business planning to keep your workloads fairly static, and you are not looking to go multi-cloud, you too can get away with using the old configuration. Building with third-party solutions requires a lot of upfront investment, and if you are not planning on this kind of expansion, the hub-and-spoke model still works.
But if you are planning to scale up in the next three to four years, add lots of new networks and create lots of new virtual networks across multiple cloud providers, the new way is a much more efficient and cost-effective solution.
If you decide to embrace transit gateways, here are two tips to keep in mind.
- AWS and multi-cloud do not mix. AWS’s native transit gateway is efficient and cost-effective for facilitating communications within the AWS environment. But it does not support multi-cloud setups yet, so if your multi-cloud environment includes AWS, you will need a third-party solution, such as Cisco or Aviatrix.
- Plan up front. If you are committed to building containers across business units, or across multiple networks, plan ahead. A lot of companies are looking at a container-first or cloud-native approach in architecting greenfield services. Google, for instance, recently released Anthos, to enable multi-cloud applications.
As cloud strategies evolve, networking strategies need to do so as well. The hub-and-spoke model of communication worked fine when organizations managed straightforward deployments within regions, within single-cloud environments. Containers and multi-cloud strategies have changed the game, creating opportunities for flexibility and efficiency. Unless you are content with your old cloud, it is time to embrace a new model for connectivity.