ra2 studio - Fotolia
In the age of overused marketing jargon, the true meaning of concepts like multi-cloud can get fuzzy.
This confusion makes it difficult to identify and build the right networking architecture and services for multi-cloud. Definitions may vary, but multi-cloud architectures don't just consist of a bunch of clouds working completely independently of one another. They require some degree of interconnectivity.
Enterprises tend to adopt a multi-cloud strategy in one of two ways: Either it's a strategic imperative from the start or it's something they evolve into over time. And while these approaches differ, the multi-cloud networking services you need are relatively the same.
To pick the right networking options, you need to start by tracking your workflows. These can extend from user to cloud, from cloud to data center or from cloud to cloud. Each workflow pattern influences the options for multi-cloud networking.
Cloud provider offerings
The major cloud platforms support user-to-cloud networks, which effectively map the cloud provider's address space for your application to an address on the internet or a company VPN. If you use multiple clouds, you can still use each provider's basic network mapping as long as your users find the proper cloud or application address via a DNS server under your control.
Cloud providers also have services like cloud-embedded virtual routers, such as Amazon's transit virtual private cloud (VPC), and private off-internet pathways -- including AWS PrivateLink, Azure Virtual Network (VNet), VNet peering and Google Cloud VPC Network Peering. These cloud networking services are easy to use and configure, and they'll get traffic back to your VPN in an optimal manner.
However, to connect these offerings in a multi-cloud environment, you'll need to use another approach, either to augment cloud provider tools or replace them.
Virtual networks for multi-cloud environments
One approach to address multi-cloud networking needs is to create a single virtual network that's integrated with the company VPN or data center. Tools like Nokia Nuage, VMware NSX and Aviatrix provide a unifying virtual layer to harmonize network connectivity in multiple public clouds and data centers. Most of these multi-cloud networking services will build another network layer, so beware of the overhead and effect on the enterprise VPN.
Alternatively, you could adopt the same SD-WAN strategy that connects small sites to the company VPN. These networking avenues can also connect to the cloud. VMware, Cisco and many other vendors offer a cloud client that can access hosted applications from the company VPN, using the internet as a transport.
Some of the SD-WAN options on the market also support cloud-to-cloud connections through a cloud client for each of the public clouds in a multi-cloud network. This provides uniform access to all clouds by all VPN users. However, these services are still subject to any corporate restrictions that might limit access for security or compliance reasons.
SD-WAN strategies are easy to apply and they don't have much effect on the rest of the VPN. However, all virtual and software-defined networking approaches define the connection model but not the connection resources. They tend to fall back on the internet as the network that underlies the connectivity, which can pose performance and security concerns for enterprises.
Real and virtual devices for multi-cloud networking
Multi-cloud organizations can also turn to networking devices in some cases. Company VPNs involve at least some traditional network devices, and data centers are typically packed with switches and routers. It's no surprise that switch and router vendors have multi-cloud strategies, based on either "real" devices or virtual routers.
Enterprises can place -- virtually or otherwise -- a device in or at the edge of the cloud and make the connections. Virtual routers are deployed in the cloud and connect cloud applications to company resources or other clouds, via the internet or company VPN connected to the public cloud providers.
The difference between the virtual-router and virtual-network approaches is subtle, but, essentially, the virtual routers are typically virtual pieces of the company VPN, whereas virtual networks tend to extend the VPN through an additional virtual layer.
Real devices can also withstand multi-cloud connection, so it's possible to haul all cloud traffic to one or more routers on a company network and let those devices provide the transit path. While this may sound indirect and illogical, the security and performance may be as good or better than the other choices.
Ultimately, when it comes to choosing the right path for your network, there are a few scenarios that fit each multi-cloud networking option.
- If all you need to do is connect multiple public clouds to your data center or VPN, the public cloud provider services are the way to do it.
- If you also have to support cloud-to-cloud connections, then consider the virtual network or virtual/real device options.
- If you have a lot of cloud applications with a lot of cross-cloud workflows, then a virtual device is probably the way to go.
- If your VPN has sites spread everywhere and supported by SD-WAN, consider using an SD-WAN for your multi-cloud.
When you decide on the right fit, check its performance and security capabilities, and you're one step closer to deploying a successful multi-cloud networking strategy.