NFV in the Cloud: It's Complicated

No one ever thought that Network Functions Virtualization (NFV) would be easy to implement. But did everyone realize how tough it would actually be?

Even the staunchest advocates of NFV as a cloud-based process admit that the cloud world is an ultra-complex environment that will require fundamentally new approaches to the orchestration and management of services. (See Clouding Up the NFV Transition.)

That's a major reason the whole process of virtualizing network functions may take longer to be fully implemented than initially thought. (See Clouding Up the NFV Transition).

While the cloud is a more dynamic and flexible environment for implementing virtualization, and the one that offers the best chance of actually achieving the efficiency and flexibility gains that has the network operators so fired up, distributing functions in the cloud can (and probably will) change every aspect of how services and applications are developed and delivered.

"In a virtualized world, an application sits in one virtual machine," says Caroline Chappell, senior analyst with Heavy Reading and one of the authors of a new report, SDN & NFV: A Revolution in the Making. "In cloud world, it may be in a number of VMs [virtual machines] in different tiers of the virtualization process -- Web, compute or storage -- and those tiers may have very different requirements, such as different thresholds for when they need to be spun up and spun down. The data tier may need to be located in a single country, for example, for regulatory reasons, but you might be able to have Web tier anywhere," explains Chappell.

Engineering challenge
As a result, the entire way apps and services are engineered in the cloud changes, as things become untethered, creating the need for a new set of orchestrations for each app and, arguably, a new approach to managing services.

And for telecom service providers to reach their ultimate goal of plug and play services and apps that are assembled from the virtualized functions located in the cloud, it is essential that these new approaches remain open and sustain interoperability, says Nik Willetts, chief strategy officer for the TM Forum.

"It's a case of knowing where you are heading," he says. "Or you can end up with a bunch of proprietary solutions that don't integrate all that well but happen to be running on virtualized bits of kit rather than proprietary bits of kit."

The challenges have not gone unnoticed by the operators keen to benefit from NFV and software-defined networking (SDN). The European Telecommunications Standards Institute (ETSI) NFV working group has described a management and orchestration layer, but that is still in development.

"If you take that concept literally, you would be adding a pretty significant software function that could be a massive development activity and a monumental single point of failure, if you have all management requests going through one thing," says Tom Nolle, president of CIMI Corp. and the catalyst behind the Cloud NFV organization. (See New Group Ties NFV to the Cloud).

Avoiding the proprietary trap
There are multiple efforts to create open interfaces to avoid the proprietary trap and any NFV deployment is likely to draw on these, including OpenStack and the work being done by the Open Daylight project. But there is still uncertainty over how all of this happens.

"Open Stack does some of the things you need -- it gives you the ability to manage the virtual machines and the network connectivity of those virtual machines, and it gives you overall visibility," says Metaswitch Networks CTO Martin Taylor. "But it doesn't do things like aggregating statistics, and it doesn't do things like monitoring the load on the systems and adjusting the number of instances of a particular process up or down to perform automatic elastic scaling."

Those developing software platforms, such as Metaswitch's Project Clearwater, are looking to a third party to provide those kinds of generic functions so they can focus on maximizing the quality and functionality of their NFV software.

"We don't know yet who is going to step up to the plate and do that software work," Taylor comments.

There is some general uncertainty hanging over the management aspect of NFV, admits Graham Finnie, chief analyst for Heavy Reading, but that's not uncommon given how early it is in this process. In its research for the above-mentioned SDN & NFV report, Heavy Reading found there is a lack of consensus among operators about how they view NFV in relation to their existing Operations Support Systems and network management processes.

Internal affairs
While some see operational changes as essential to taking advantage of the scalability and elasticity that virtualization is promising, others are too wary of internal organizational issues and would prefer the that any implementation of NFV and SDN capabilities doesn't touch their legacy OSS, Finnie says.

"At this point, it's a real dog's dinner," Finnie says, like a true Brit.

Speaking of food for thought, the final article in this mini-series looks at what CloudNFV and others have cooked up to address these virtualization complications.

— Carol Wilson, Editor-at-Large, Light Reading