I’ve predicted that virtual networks will be hot in 2023, but that begs the question of what exactly a “virtual network” is. One definition says, “not physically existing as such but made by software to appear to do so”, and that surely makes you wonder how businesses would be willing to commit to such a thing. Truth is, they already have, but I think it’s time to look closely at the concept of virtual networks, and to categorize what exactly is going on there. Why look at something that isn’t real and only appears to be? We’ll see.
I could offer a lot of discussions on the early days of virtual network evolution here, but they’re probably as useless as a debate on where your lap goes when you stand up, an example of worthless effort I recall from a childhood book. Instead, let’s look at virtual networks from two directions—the user and the application—and see how those two directions are shaping virtual network technology, increasing its importance, and converging on a new network model overall.
The most ubiquitous virtual-network thing we have in the data center may not be what you’d think of as a virtual network at all. I doubt there are any users anywhere who don’t use private IP addresses. Your home internet is supported on a private IP address, and popular container technologies use private IP addresses as well. These addresses are called “private” because they exist only inside an IP subnet, and using them in container networks means that components of an application can communicate locally but can’t be externally referenced unless they’re explicitly exposed by linking them to a public address.
The problem with private IP addresses is that they aren’t unique, which means users’ traffic and connectivity could get mingled, creating security and SLA issues. The data center usage of what we could perhaps call “real” virtual networks came about as a way to keep users (tenants) of cloud and other virtual-hosting services separated. Public clouds use virtual networks, and vendors including Cisco, Juniper, IBM/Red Hat, Nokia, and VMware offer commercial virtual-network products. These are based on what’s called an “overlay” technology, meaning that traditional LAN or IP networks carry another layer of addressing, the virtual network addresses, and there’s another layer of routing that directs packets based on the addresses at this new layer.
This virtual-network model reaches beyond the data center, too. You can create a virtual network that’s laid on top of your real IP network, and its users can communicate only with other members of the same virtual network, which is sort of like a closed user group. That means that modern virtual networks can separate tenants/users, applications, organizations, or whatever you like, all without changing the real network below. It’s almost application- or mission-centric networking. However, enterprises have been slow to adopt a comprehensive virtual-network model.
Arguably the biggest development in virtual networking came along from the user side as a result of the growing cost concerns regarding the connecting of small sites to the company VPN. Traditional VPNs based on MPLS require usage of border gateway protocol (BGP), routers, and often some form of carrier Ethernet access, all of which can drive small-site connection costs so high that CFOs cringe at any suggestion that the sites should be on the company network. But, as worker empowerment through application and data access became more important to businesses, they were trapped. So along came SD-WAN.
SD-WAN stands for software-defined wide area network, and its goal was to establish a virtual network over internet access to small sites, linking them back onto the corporate VPN at some convenient place. This new virtual network then extends the corporate VPN address space and connectivity, but using the same Internet technology available at low cost to any small business site or residence. You still need an on-ramp for SD-WAN, but it doesn’t have to be a router running BGP, and in fact it can be a software component that’s hosted on any convenient resource.
Including the cloud. From the first, many SD-WAN vendors offered a software component that could be hosted in the cloud, and that could then join a cloud application or application component to the company VPN. This capability could be used to increase the security of cloud applications, and to (at least partially) unify (in a network connectivity sense) the cloud, the data center, and the user community.
The reason for that qualifier is that SD-WAN was never aimed at networking the data center, only at getting remote users or cloud elements connected back onto the corporate VPN. If a virtual network is used to separate applications or groups of users from each other, then somehow uniting those capabilities with SD-WAN would be required, or the two virtual networks might interfere with each other.
The interesting thing is that all those virtual-network providers I named earlier also offer SD-WAN in some form. It would seem inevitable that someone would have united SD-WAN and the data-center-centric virtual network technology, but that really only emerged in earnest in 2022. Of the enterprises I’ve chatted with who use one or the other of the technologies, less than a tenth integrate the two in any way, and all but one of those had worked through that integration only in 2022. The reason they got virtual-network-smart was the cloud.
When SD-WAN was extended to the cloud, and when it became the centerpiece technology for the secure access service edge (SASE) wave, it would seem that somebody should have figured out that the cloud mission for SD-WAN meant that serious attention should be paid to the integration of SD-WAN into a total virtual network model that included the data center. Concepts like cloud backup for data-center elements or “cloudbursting” load sharing between data center and cloud would ordinarily demand a common network model across all hybrid-cloud relationships, after all.
Hybrid cloud is the reason 2022 saw some explicit efforts by vendors to link the two virtual-network technologies. Unfortunately, almost every user I chatted with last year said their vendors had not told then about the capability or explained why it was not only valuable but likely essential. If your company uses the cloud (it would be astonishing if you didn’t, but even so you likely will be in the future), you should be pressing your vendor for an approach to unify them. Even if it means you have to change your virtual-network vendor or vendors, a single model is essential if you’re to get the most from the cloud this year, and beyond.
Copyright © 2023 IDG Communications, Inc.
