Network functions virtualization (NFV) has been a fairly popular buzzword over the last few years. The promise of enabling network services to run on standard “commodity” hardware as opposed to expensive propriety hardware was quite enticing. After all, standardization has driven so many innovations in tech over the years, the potential benefit of NFV seemed clear: lower costs and vendor lock-in while increasing agility and scalability for end users. Unfortunately, NFV has been unable to deliver on its promises for a number of reasons, including unnecessary complexity, high costs, and less than stellar performance.
On the other hand, over the same period of time, SD-WAN has seen tremendous growth and enterprises across the globe are adopting it at rapid rates. SDWaaS (SD-WAN as a Service) in particular is succeeding in many areas NFV has thus far failed. While many are familiar with the concept that SD-WAN is the modern replacement for MPLS (Multiprotocol Label Switching), the idea that SDWaaS can succeed where NFV has failed is often overlooked.
In this piece, we’ll dive into what NFV was supposed to do, where it has gone wrong, and how SDWaaS is succeeding in its place.
The four layers of NFV
NFV was supposed to abstract the complexity and proprietary hardware that is common on enterprise networks. NFV is a framework that includes four layers:
- OBSS- The Operational and Billing Support System layer is used to facilitate billing by and support by service providers. It captures data from the MANO layer.
- VNF- Virtual Network Functions are capable of running as virtual machines and providing network functions that were normally performed by proprietary hardware (e.g. routers, firewalls, WAN appliances, etc.). VNFs sit atop the NFVI layer.
- NFVI-Network Functions Virtualization Infrastructure layer is somewhat analogous to a bare metal hypervisor and the underlying hardware. NFVI provides the virtualized compute, storage, and network resources used by VNFs.
- MANO- Management and Orchestration layer communicates with all three other layers and enables provisioning, configuration, etc.
(Source: Network Functions Virtualization (NFV) With a Touch of SDN)
By enabling network functions to run on commodity hardware, NFV was supposed to bring the flexibility of virtualization to the enterprise network. Doing so would in turn lead to reduced capex and opex, less vendor lock-in, and more scalable, economical, and agile IT operations.
Where has NFV gone wrong so far?
While all this sounds like a great idea, the execution to date has been lacking. As opposed to an ecosystem of standards-based, interoperable, flexible solutions that reduce vendor lock-in and drive down prices, enterprises have gotten full stack solutions from a handful of vendors. As opposed to more choice, enterprises are simply being locked in to specific providers due to lack of information and interoperability in the world of NFV.
Further, to date, NFV hasn’t been delivering as well as it should on the promise to reduce capex. The hardware required to virtualize all network functions and still deliver comparable performance often ends up being similar to the cost of the proprietary appliances they are supposed to replace.
Additionally, network service providers have often struggled to identify a compelling business reason to make the shift to NFV. There is often simply too much complexity in transitioning to NFV and this complexity in and of itself outweighs any potential benefits given what NFV is able to deliver today.
That last point about complexity as a barrier for service providers is an excellent microcosm for what may be the biggest problem with NFV: while it was supposed to abstract away complexity and make IT ops more flexible, in its current form it often adds complexity. This paradigm likely won’t change unless there is a significant shift in the world of NFV. As is, the providers of VNFs are not incentivized to make it easy to change vendors or grant another tool the ability to control and configure their solutions at a granular level. This means NFV appliances may be able to manage multiple VNFs to an extent, but multiple proprietary VNF management solutions from VNF vendors are still needed in many cases, which in turn reintroduces complexity.
How does SDWaaS get it right?
There may still be some hope for the NFV market to begin delivering compelling solutions in the years to come. However, enterprises looking for a robust, economical, and scalable way to get the most out of their WAN optimization efforts today should look no further than SDWaaS.
One of the biggest problems in the world of NFV is that multiple parties have varying incentives that conflict with one another and result in users getting suboptimal results. SDWaaS offers enterprises an integrated, feature-rich, and secure platform of microservices. SDWaaS enables WAN traffic shaping (e.g. using QoS), Policy-based Routing (PbR), Next-Generation Firewalls (NGFWs) and many more WAN optimization and security features in one holistic solution.
This means organizations that adopt SDWaaS will be able to improve the performance, security, and reliability of their WAN while abstracting away the complexity of multiple hardware and software appliances today. No waiting for an industry to deliver on potential, SDWaaS is capable of doing what NFV one day hopes to.
SDWaaS executes where NFV has failed
As we have seen, NFV is still not capable of delivering on its initial promise. On the other hand, SDWaaS is delivering WAN optimization results today and has surpassed both NFV and MPLS as “the way of the future” for the vast majority of enterprise WAN use cases.
The reason SDWaaS is able to deliver where NFV has failed is simple: SDWaaS offers a complete integrated solution while NFV is still waiting for multiple parties to overcome conflicting interests and deliver real value to end-users WAN optimization efforts.