Network Function Virtualization (NFV) is an emerging platform to deliver network and security functions as a managed service. Network service providers (NSPs) have been piloting, and in some cases offering, NFV solutions to enterprises. At the core of NFV is the notion that network functions, such as SD-WAN, firewalling and secure web access, can be delivered as virtual appliances and run either on premises (vCPE) or at the carrier core data centers (hosted).
NFV is a huge undertaking for NSPs, involving many moving parts that are partly outside their control. The ramification of which is both the NSP and enterprise will realize only minimal cost and operational benefits. Despite the hype, NFV may not be worth deploying.
The Four Architectural Challenges of NFV
NFV includes two key elements:
- An orchestration framework that manages the deployment of specific network functions for each customer into the desired deployment model, vCPE or hosted.
- The Virtual Network Functions (VNFs), which are third-party virtual appliances being deployed into the vCPE.
This architecture has several key challenges.
1. VNF resource utilization is heavily dependent on customer context.
For example, the volume of encrypted traffic traversing a firewall VNF can dramatically increase its resource consumption. Traffic must be decrypted to enable deep packet inspection required for IPS or anti-malware protection.
2. Running VNFs at the carrier data centers requires a scalable and elastic underlying infrastructure.
As the load on VNFs increase, extra resources need to be allocated dynamically. Otherwise, carriers risk impacting the other VNFs sharing the host.
To avoid this problem, carriers have a few choices:
- They can underutilize their hardware, which defeats a major benefit of virtualization.
- They can try to migrate the VNF in real-time to a different host, but moving an instance with live traffic is a complex and risky process.
- They can associate every VNF with a specific hardware platform, such as a blade with dedicated CPU cores, memory and disk capacity. With this approach, cross-VNF impact is reduced, but once again the main benefit of virtualization, maximizing usage and reducing cost of hardware infrastructure, is lost. This in turn impacts the enterprise whether through increased price or reduced service quality.
3. Running VNFs on a physical CPE creates a risk for cross-VNF processing and memory degradation of the underlying appliance.
Some VNFs, such as routers and SD-WAN, consume relatively few resources. Others, such as URL filtering, anti-malware or IPS are very sensitive to the traffic mix and will require more (or less) resources as traffic changes. Sizing CPEs is not a trivial matter and forced upgrades will become routine.
4. NFV management is per vendor, leaving it complex and fragmented.
While the NSPs can “launch” a VNF, the VNF software and configuration live inside a “black box.” The NSPs have limited ability to control third-party VNFs. VNF vendors maintain their own management consoles and APIs, making centralized management cumbersome for both customers and service providers.
There several reasons to be skeptical that a multivendor orchestration and management standard will materialize. For VNF vendors, customer retention relies on the stickiness and vendor-specific knowledge of their management consoles. A unified multi-vendor orchestration and management platform runs counter to their interest. For NSPs, customer choice means a big impact on their managed services capabilities. It will be difficult for NSPs to offer a managed service for every VNF, if a VNF requires proprietary management.
Beyond NFV: Network Function Cloudification
Despite the industry hype, NFV will largely look like the managed or hosted firewalls of the past, with some incremental benefits from using virtual instead of physical appliances. Customers will end up paying for all the appliance licenses they use, and they will still need to size their environment so they don’t over- or under-budget for their planned traffic growth.
From a managed service perspective, offering to support every single VNF vendor’s proprietary management is an operational nightmare and a costly endeavour. Ultimately, if NFV does not allow NSPs to reduce their infrastructure, management, and licensing costs, customers will not improve their total cost of ownership (TCO), and adoption will be slow.
Network Function Cloudification (NFCL) breaks the appliance-centric architecture of NFV. Unlike VNFs, Network Cloud Functions (NCFs) are natively built for cloud delivery. Instead of separate “black box” VNF appliances, functions are decomposed into discrete services – the NCFs. These may be any network function, such as SD-WAN, firewalls, IPS/IDS, secure web gateways and routers. Regardless, they can be then deployed anywhere, scaled vertically by adding commodity servers, or horizontally through additional PoPs. Wherever PoPs are deployed, the full range of NCFs is available, and load is continuously and dynamically distributed inside and across PoPs.
Unlike VNFs, no specific NCF instance is “earmarked” for a specific customer, creating incredible agility and adaptability to dynamic workloads. NCFs are configurable for each customer, either on a self-service or as a managed service, through a single cloud-based console.
NCFs promise simplification, speed and cost reduction. In some cases, these benefits come at a reduced vendor choice. It’s for the enterprise to decide if the benefits of NCFs are greater than the cost, complexity and skills needed to sustain NFV-based, or on-premises networking and security infrastructure.