NFV tried to bring the network to the cloud. Now, it’s time to bring 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.

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.


To learn more, watch the Light Reading webinar:
The Disaggregation of Networks is Already Happening

Watch Webinar

NFV tried to bring network function to the cloud

NFV attempted to bring network functions to the cloud. Yet 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 for bringing network function 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.

Many 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.

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.

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.

Bring the cloud to the network

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.

About the author

Ludovic Rubin, Director of Product Marketing
Ludovic is Director of Product Marketing at DriveNets. Ludovic has 20 years of experience in product management, product marketing and business development, primarily in the field of telecom (mobile networks, OSS/BSS and video) and enterprise applications.
Ludovic holds a Master of Science (MsC) in Computer Science and Electrical Engineering from Ecole Centrale de Lyon (France), a post-masters’ degree in mobile communications from Telecom ParisTech and completed the Management Accelerator Program at INSEAD.

Skip to content