SSilver - Fotolia


Virtual network functions, not network functions virtualization, belong in enterprise

While network functions virtualization is exclusively a service provider technology, virtual network functions are at home in the enterprise space.

I occasionally encounter vendors who are marketing network functions virtualization (NFV) to enterprises. Given how the industry tends to stretch and twist the definitions of buzzwords to the point that they lose all meaning, I advise against pushing NFV on enterprise IT organizations. NFV is a service provider technology, plain and simple. However, these vendors do have a point. There are some parallels to NFV in enterprise data centers, where many network services and security appliances have been virtualized, and the industry has some work to do with this technology. Enterprises need help with managing this virtual infrastructure.

NFV is an architectural specification project led by the European Telecommunications Standards Institute (ETSI). Its aim is to develop an architecture and vendor ecosystem that will enable service providers to virtualize network functions that are traditionally delivered in proprietary hardware appliances. NFV promises to deliver increased agility in service provider networks, along with lower operational overhead. Virtual network functions (VNFs) are just one piece of the NFV puzzle. ETSI's NFV specification group is defining orchestration and management technology, too. These are the trickier pieces of the puzzle. A whole conference dedicated to the problem, VNF Management and Orchestration, will take place in Barcelona in late April.

Given that virtual network functions have existed in enterprise networks for more than half a decade, some vendors are quick to co-opt NFV for the enterprise. It makes some sense, but enterprises need to be careful. ETSI is developing an architecture for service providers, not enterprises. While enterprise data center operators might be able to adopt some of the architecture of NFV, they should demand something more specific to enterprise use cases. After all, no enterprise network engineer is ever going to be tasked with virtualizing the evolved packet core for an LTE network. So, why would they adopt an architecture built to support such a use case?

When I look at enterprise data centers today, I see all kinds of virtual network functions: application delivery controllers (ADCs), firewalls, VPN concentrators, routers, etc. Some are deployed on dedicated x86 servers. Others are deployed on shared hypervisor hosts, side-by-side with VMs hosting the enterprise applications these VNFs serve or protect. Data center teams were using these VNFs before anyone coined the terms NFV or SDN. Early on, enterprises recognized the lower costs and the operational agility a software appliance offered over hardware.

Virtual network functions are just one piece of the NFV puzzle.

But how do you manage the lifecycle of those VNFs? A data center that leverages a great many VNFs from multiple vendors may soon find that it's dealing with virtual appliance sprawl. Sure, every vendor from F5 Networks to Palo Alto Networks allows you to manage its virtual appliances via the same management software it offers for its hardware-based products. But in a software-defined data center where instances of VNFs are spun up programmatically by cloud admins or even application developers, how can you be sure that those VNFs are properly managed? If a cloud admin spins up several virtual ADCs and firewalls to support a burst of application activity, the operations team will need assurances that those new instances will be spun down again when no longer needed. Otherwise, the data center will be needlessly burning compute resources and licenses for idle VNFs.

Many network virtualization overlay (NVOs) vendors have opened up their APIs so that VNF vendors can integrate with them. The NVO then provides a service insertion point for VNFs. But they don't manage the lifecycle of those appliances. They certainly don't monitor and configure them. OpenStack and other orchestration technologies offer some management capabilities for select types of VNFs in an enterprise context, too. But the OpenStack APIs for load balancer as a service and firewall as a service are still maturing.

Many traditional, third-party network management vendors are also adapting their products to deal with VNF sprawl. In some ways, network management vendors have a leg up. Many aspects of managing VNFs are identical or at least analogous to managing their hardware-based counterparts. But programmatic data centers will challenge the ability of all of these technologies to properly manage VNFs. Also, VNFs simply aren't the same as hardware. Some enterprises often rely on geographical topology maps to track the performance and availability of network devices, including ADCs and firewalls. When those appliances are virtualized and distributed across hundreds of hosts, that management approach breaks down.

VNF management remains a challenge for both service providers and enterprises. If service providers are still figuring it out, then the enterprise market clearly has its work cut out for it. ETSI is leading the charge for service providers. Someone else needs to help enterprises.

Next Steps

Building a virtual network functions framework takes planning

How network functions virtualization will make architectures more cost-effective and flexible

Learn more about the benefits and drawbacks of virtual network appliances

This was last published in March 2015

Dig Deeper on Network virtualization technology