What a Virtual Network Looks Like: Services
A service future that could change infrastructure and everything else in IT and networking could be closer than we think.
If "you are what you eat" is the foundation concept for nutritionists, then "you are what you sell" should be the equivalent for network operators and service providers. The purpose of the network is to build services, and that should be true whether the network is "virtual" or real. In fact, services may be the most virtual thing about the network of the future, and the differences between virtual services and traditional services may be the primary drivers for change.
In the past, services have been the direct product of cooperative behavior of systems of network devices. The devices communicate with each other to learn network topology, status, and the location of endpoints in a process called "adaptive discovery." This collection of adaptive processes ties networks tightly to protocols and ties devices to services, which means that service changes can demand protocol and sometimes even device changes. If virtual networks can break this tie, it could be... well ... huge.
Services divide into three basic categories -- connection services, on-network hosting services, and endpoint services. Connection services are the things that move traffic among endpoints; hosting services are services offered on the network (websites and the cloud); and endpoint services are things like firewall, network address translation, dynamic host configuration, and so forth that are offered per (and usually at) an endpoint and appear to be a logical part of a connection services. A big, perhaps even the biggest, question for virtual networks is how they'd relate to these three classes.
The big advantage these virtual network services offer in the "connection services" category is that they scale almost infinitely whereas virtual networks based on Ethernet or IP have limited scalability. This is why virtual switches have exploded in cloud data center applications -- if you wanted, you could have a virtual network for every user, every organization, and every application.
Combining virtual networks in branch offices and workgroups with virtual networks per application could allow enterprises to connect workgroups or users to applications only where allowed. It could revolutionize the notion of security. Collaborating teams, even in different companies, could share tools and information without actually connecting their company networks -- only specific users would share specific tools and data.
If virtual networks let you compose virtual networks from a collection of users and applications, virtual connection-point services could let you compose features. With network functions virtualization (NFV), you could deploy security, monitoring and management, addressing, and even load-balancing tools as needed, move them around to follow users or applications, and change or modernize the features when better stuff is available -- all without changing out any devices.
Virtual network services can be built using overlay networks like the one pioneered by Nicira ( bought by VMware) or those used by software-defined WAN vendors to offer connection services that blend multiple VPNs or the Internet. These overlay-network services would normally mesh their endpoints with tunnels, but NFV could be used to host instances of switches/routers at critical traffic points to make the implementations more scalable. These instances could also link application and worker/workgroup virtual networks as described above.
Many of the endpoint or service-edge tools we take for granted are problematic in a cloud context. Take load balancing; just figuring out where to put a load balancer when multiple processes are distributed in the cloud to offset increased use is problematic. For Domain Name System (DNS) services, you may need to spawn a load balancer "behind" a DNS if you add instances of an application, and of course you have to change the IP address a DNS returns if you've moved the process in the cloud. What this means is that even if a new connection-service virtual-network model didn't benefit from new connection-point features, a cloud-centric implementation of the feature could provide real value to users.
One new and exciting opportunity for connection-point services is the Internet of Things (IoT). It's impractical to assume that mobile phones used for IoT applications ranging from navigation to identifying retail locations as you walk past them would require every phone to query every IoT sensor directly. Instead, a special service could be deployed by NFV to collect sensor data for all navigation or shopping applications, and then import the data into a user's own virtual network connection.
This IoT example illustrates that connection-point and hosted services have a very fuzzy boundary. Even security functions might be offered as dynamic features "added" to a network to analyze emails or website access and detect an infection. One of the values of an NFV model where pools of hosting are distributed through a metro area is that features could be spun up dynamically, and there's relatively little difference between features that appear to the user to be virtual CPE and those that might look like a remote website or database.
It may be that all the service drivers for virtual networking reduce to the same thing, this notion of dynamism. You build networks ad hoc both in terms of connectivity and features, and you personalize network services to every workgroup, application, branch office, or even user. Access to everything is explicit -- you have to be joined to a resource to even see it, whether the resource is human or an IT element. Best of all, this is agile and optional in that you can still build a traditional open virtual network or build one that's totally access-controlled and feature-regulated. This kind of service future could change everything in IT and networking, not just network infrastructure, and it might be closer than we think.
Read related posts:
Follow Tom Nolle on Google+!
Tom Nolle on Google+