Network Function Virtualization (NFV) has garnered significant attention ever since its first public appearance in 2012 when the formation of the ETSI Industry Standards Group (ISG) was announced in an operator-led white paper. NFV landed at the peak of the Gartner Hype Cycle for Networking and Communications in 2013, and was last seen sliding towards the trough in the 2015 edition.
Operators clearly have plans to continue to invest in NFV – but only where it makes economic sense. It seems as if the industry has backed away from the confirmation bias that first enthralled it with regard to NFV. Instead of blindly adopting NFV on the belief that CapEx improvements would result from general purpose, or “off the shelf” compute nodes, and that operational transformation would yield OpEx benefits, we are now seeing operators more deliberate in driving NFV into particular use-cases that have quantifiable benefits. I view this as a positive for the industry.
In parallel, we are now in the 2nd iteration of NFV – maybe not from a standards perspective, but certainly from a vendor development and investment perspective. I thought it made sense to share a blog on my perspectives of where NFV has been, where it is now, and where it is going from a technology perspective, and open the floor for debate.
Where We’ve Been – NFV 0.1
Since 2013, we have seen numerous vendors, both existing hardware infrastructure suppliers and startups capitalizing on the lower barrier to entry due to the shift from proprietary hardware appliances, which requires significant venture capital and engineering investment, to software, or virtual, appliances. The development of virtual appliances – either organically, or as software representations of the physical infrastructure they were derived from – was not, in my opinion, the goal of NFV – to drive a new level of innovation into networking.
Instead, what we got with this first iteration of virtual appliances was a carry-forward of the same limitations and same boundaries as those that existed in the physical world. While this was progress, and gave the industry an opportunity to continue to learn how to do networking on x86 servers, this path introduced a number of inefficiencies when the virtual appliances share the same physical resources (compute, memory, network I/O). What was missing with these first virtual appliances was the opportunity to rethink where the boundaries of a virtual appliance exist and where the split between virtual functions truly belong.
Where We Are – NFV 1.0
This is where, I think, the industry currently is – at the evaluation of how and where virtual functions should get combined as a means to eliminate redundancies in memory, in processing, etc. Virtual appliances have given way to Virtual Network Functions (VNFs), focused on redefining what the functional network boundaries should look like in a virtual environment. This is not a simple evolution from virtual appliances to VNFs, either – in many instances, it requires major modification of the software stack to no longer rely on the hypervisor as crutch for the software, obfuscating the hardware upon which it was running. The result of this process will be a new set of virtual network functions, designed for, and optimized for use-cases, and realized on shared, general purpose computing infrastructure. For the industry, this is a major step forward – simplifying NFV into existing operational silos yields a low-barrier mechanism to larger-scale NFV adoption. But, its not the end of the NFV journey, either.
Where Are We Going – NFV 2.0
Going forward, we will see a further evolution of NFV, beyond the functional aggregation that marks the turning point for NFV, and the elimination of virtual appliances from the industry in favor of new VNFs. With changing operations processes in Telco, we can expect to see that VNFs will no longer be constrained to the vertical operational silos that they are today. I expect to see two major iterations of NFV happen:
Disaggregation of VNFs themselves into independently scalable, location-independent control planes and data planes, similar to the network-wide trend with SDN.
Incorporation of a Hardware Abstraction Layer (HAL) that untethers NFV from the x86 architecture, and embraces alternative computing environments, including adopting extensible, protocol-independent programming languages, such as P4 (p4.org).
By enabling independent scaling and eliminating location co-dependence of control and forwarding planes, and extending deployability to an increased diversity of hardware, NFV 2.0 will allow workloads to reside on the most efficient processing environment, at the most ideal physical location (Cell Site, Central Office, Backhaul Aggregation, IP Peering Points, Data Cetners) for that particular task.
To me, this is when the industry starts to realize the full potential of NFV as a technological and operational leap forward.