Operators have firmly identified VNF architecture as the next hurdle on the critical path to NFV, and the clamor for cloud-native VNFs is growing rapidly.

Caroline Chappell, Contributing Analyst, Heavy Reading

June 15, 2016

4 Min Read
Telcos Clamoring for Cloud-Native VNFs

Speaking on "The Composable Telco" panel at Light Reading's Big Communications Event in Austin at the end of May, Doug Nassaur, General Manager and Lead Principal Technical Architect for AT&T's Domain 2.0 initiative, pointed out that virtualized network functions (VNFs) urgently need to be developed as cloud-native applications, because early virtualized versions consume far too much hardware in their quest for high availability.

Nassaur represents AT&T Inc. (NYSE: T) in the Open Container Initiative (OCI) and Cloud Native Computing Foundation (CNCF), and his is not the only voice urging the telecom industry to produce cloud-native VNFs as soon as possible. BCE keynote speaker, David Amzallag, head of SDN and NFV at Vodafone Group plc (NYSE: VOD), announced that he has put network equipment vendors on notice: Vodafone will only buy VNFs designed specifically to operate in the cloud from now on. (See BCE 2016: A Sea Change at Vodafone.)

A growing number of operators are similarly supportive of the cloud-native movement, including Deutsche Telekom AG (NYSE: DT) and Tele2 AB (Nasdaq: TLTO). In March 2016, the latter explained the problems with the current generation of VNF software, ported straight out of appliances into large, stateful, monolithic VMs. (See NFV App Architecture Must Improve – Tele2.)

Tele2 also made the excellent point that operators can't rely on the NFVi and VIM (typically OpenStack) alone to guarantee the carrier-grade performance and reliability of VNFs.

Panelists on BCE's New Telco Data Center panel agreed. They reckoned that operators can score six nines of availability across low-cost NFV infrastructure as long as VNFs have been architected to expect its failure. VNFs should be immune to switch, fan, CPU, VM and even whole availability zone crashes, maintaining service resilience and the right customer experience despite them.

The endgame of NFV is to take the network into the cloud for elasticity and scale. As I pointed out at the now-distant Executive Summit Light Reading held in Iceland at the end of 2014, the cloud is a holistic system. It is baked from a number of ingredients, all of which need to be present at the same time for the cloud to function. The cloud is simultaneously based on: commodity, "throwaway" hardware; a highly modular, scalable and available application architecture; and robust orchestration that treats applications as disposable "cattle."

Operators that wish to build the cloud have a problem: There are currently very few "cattle" VNFs around, so a major ingredient is missing. To compensate, the telecom industry has spent considerable effort on scoping and building a carrier-grade infrastructure for NFV. There is a lot of focus on shoehorning into OpenStack the means to guarantee the carrier-grade availability, performance and security of large, stateful and fragile first-generation VNFs. But this is not a sustainable, long-term solution for network virtualization -- as the leading operators mentioned are very well aware.

So they are ratcheting up the pressure on VNF vendors to change. This will be a difficult process: Established network equipment vendors have millions of lines of highly tested and tuned code that don't translate easily into a cloud-native architecture, and they need to keep up with demand in their current businesses while trying to transition to the new cloud world. There are challenging technical issues to overcome: how to handle state; what VNF management looks like in a cloud-native environment; the impact of cloud-native practices, such as continuous integration, on the VNF control plane; and the maintenance implications for cloud-native VNFs.

There are lessons to be learned from the experience of designing IT applications for the cloud, but as the industry now appreciates, many VNFs have very different requirements from IT applications, and the jury is still out on whether the two can, and will, start to resemble one another in a cloud-native context.

The clamor for cloud-native VNFs is growing and will only get louder over the next couple of years. Operators have firmly identified VNF architecture as the next hurdle to leap on the critical path to NFV.

Join our discussion of Reliability, Availability, and Serviceability at Cloud Scale on Wednesday, June 15, at 12:00 p.m. EST. This Red Hat-sponsored webinar will offer advice to operators and vendors seeking a holistic, cloud-based answer to the challenges of carrier-grade NFV.

This blog is sponsored by Red Hat.

— Caroline Chappell, Practice Leader, Cloud & NFV, Heavy Reading

Read more about:

EuropeAsiaOmdia

About the Author(s)

Caroline Chappell

Contributing Analyst, Heavy Reading

Caroline Chappell leads Heavy Reading's research into service provider cloud adoption for internal IT, enterprise service delivery and network functions virtualization (NFV) purposes. She also covers technologies that support telco application development and delivery and customer experience management. She is currently tracking the impact of SDN and NFV on telecom organizations and has a major interest in the new architectures and management systems needed for operating SDN and NFV-based networks. Caroline has over 20 years' experience of researching and writing about the ICT industry for global analyst firms and her work synthesizes a broad understanding of ICT innovation with a deep knowledge of telecom market dynamics.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like