December 2, 2019

Director of Product Marketing

Beyond NFV: Bringing the Cloud to the Network

Despite its promise to lower CapEx, improve service agility and reduce vendor lock-in, Network Function Virtualization (NFV) has not lived up to its expectations. And many are beginning to openly claim that NFV’s problems may be fundamental, not just the “labor pains” its proponents claim.

Beyond NFV: Bringing the Cloud to the Network

One possible symptom of NFV’s core failings may be the numerous standards and organizations which have sprung up around it since the beginning of NFV eight years ago. Meanwhile hyperscalers have already solved it in a whole new way, making their compute and storage workloads ready for mass scale and high agility in what we call cloud computing.

What is Network Functions Virtualization (NFV)

Network functions virtualization (NFV) is a way to virtualize network services, such as routers, firewalls, and load balancers, that have traditionally been run on proprietary hardware. NFV allows for the separation of communication services from dedicated hardware, such as routers and firewalls. This separation means network operations can provide new services dynamically and without installing new hardware.

Pains of NFV Cloud

While NFV attempted to bring network functions to the cloud, it did so by extracting existing network functions as-is from single-purpose appliances and placed them into virtual machines running over COTS hardware. In essence, porting networking functions as monolithic applications into virtual machines, not taking advantage of the benefits of a true cloud-native software.

While the current NFV model can work for single tenant customer-facing VNFs like SD-WAN and vCPE, it falls short for supporting high-scale network functions and multi-tenant environments.  It’s just like pushing a round peg into a square hole – a very challenging situation.

Technical Challenges of Bringing NFV to the Cloud

Wherever they run – embedded in a device or in the cloud – monolith applications remain monolith and are not built for new and quick service creation, fast error recovery or automatic scaling. Scaling monolithic network VFs lacks effective resource optimization.

Maintaining network services (core, aggregation and some edge services) require high throughput and low latency. Standard x86 hardware cannot support these requirements – we tried, it did not work – or demand special tweaks like hardware acceleration which is still limited in the cloud.

To learn more, watch the Light Reading webinar:
Network Operator Plans for Disaggregation

Operational challenges of bringing network function to the cloud

Deploying and managing NFV for high throughput and low latency network services is technically challenging. It requires complex orchestration and tweaking of physical and virtual resources.

Business Challenges of bringing network function to the cloud

VNF vendors, who mainly the same as the appliance vendors, have kept their NFV software cost model unchanged, creating a small CapEx reduction that cannot offset the higher OpEx created by the NFV operational overhead.

The NFV objectives to increase overall agility, operational efficiency and reduce costs have disappointed several Service Providers that we have been talking to. As of today, NFV is limited to specific use-cases and places in the network (mostly at the access) and hasn’t picked up widely.

Networking Service Providers Need a Better NFV

So, service providers are back to square one. To maintain profitability, achieve operational flexibility and bring new services to market faster – they need a better NFV. This is where cloud-native comes in. A cloud-native implementation of NFV – an architecture that adapts cloud technologies to networks, not networks to the cloud, can work.

DriveNets redefines NFV

DriveNets redefined NFV starting with network-intensive workloads. We separated the control plane – implemented as a cloud-native application – from the data plane – running on network-specific, low cost white boxes – to deliver the following:

  • Network agility – cloud-native software built with containerized microservices, enabling the support of any services, on any port, at any scale over a shared virtualized infrastructure of white boxes. This model supports both network services and enables external third-party services.
  • Flexible scale – the physical shared infrastructure of our Network Cloud model, can easily grow from 4 Tbps to hundreds of Tbps with a telco-grade quality, by simply adding more white boxes.
  • Easy manageability – just like managing one device, white box clusters – a group of white boxes – operate as a single VNF entity and can be managed by any third-party orchestration or management system.
  • Low TCO – the use of low cost hardware, better resource utilization, cloud-native automation and availability of fixed software license fee, all lead to both significant Capex and Opex savings.

Telcos Need to Build Hyperscale Cloud Foundations for NFV

We believe that NFV must adopt what hyperscalers have successfully done in the cloud, and adapt it to service provider networking. There is no other way. Containers, microservices, cloud orchestrators, network-specific low-cost white boxes are all available and are the way to go. NFV tried to bring the network to the cloud. Now, we can bring the cloud to the network. That’s all it takes.

Light Reading webinar on demand

Network Operator Plans for Disaggregation

Watch Now