Network functions virtualization (AKA NFV) has been around for couple of years now, and I’ve recently seen a growing number of posts and articles that try to declare victory or failure of NFV, as well as point out some of the challenges behind NFV adoption.
I would start by saying that there seems to be a lot of confusion about what is being referred to when the term NFV is used, and therefore the way  we measure its success or failure.
For example, if we consider SD-WAN adoption and wifi virtualization  part of NFV, then it would be considered  a huge success, however if the metric is the network virtualization of the core CSP networks, the adoption of NFV has been significantly slower.
The recent post by Fergus Wills on SDxCentral Why Problems With Service Chaining Are Stalling NFV refers to the challenges of handling service chaining of a video traffic management system.  One of the key points that Fergus referred to is the challenge of scaling in a heterogeneous landscape.
In another post, No quick fixes when it comes to VNF interoperability by Monica Alleven, Mazin Gilbert, vice president of advanced technology and systems at AT&T Labs and chair of ONAP’s technical steering committee,  was interviewed and referred to the importance of VNF interoperability for AT&T. In the same article, John English, senior solutions marketing manager, Service Providers, at NetScout, pointed out to the lack of a common framework and agile process for supporting VNF providers as one of the challenges that is slowing down the transformation of VNFs.
The TMForum released a detailed survey which highlights  one of the key challenges as  the fact that many NFV projects weren’t built for a “rip and replace approach”, and rely on vendors that are by definition disincentivized to virtualize their legacy network products and change their business model.

Prioritizing operational inhibitors of NFV

The TMForum survey provides interesting insight not just to the technological inhibitors, but also ranks them by the order of importance.
It’s interesting to see the the lack of sophisticated orchestration marked as one of the key inhibitors to successful NFV transformation.
If we look at the two challenges listed above  together, it’s fair to assume that sophisticated refers to the ability to combine virtual and existing network services under the same automation scheme, as well as the flexibility to orchestrate across the different layers of the stack (VNFM, NFVO, Service Orchestration and other core networking needs.)

What can we do to fix it?

If we draw a common line from all the challenges, it seems that the key challenges are centered on the fact that most of the core VNFs haven’t fully embraced virtualization, nor a cloud native approach — both technically, as well as from a business model perspective. One of the key reasons for that is the byproduct of a lack  of a common framework that will greatly simplify the adoption and development of virtual network functions.
Such a solution needs to be designed in a way that it will allow interoperability between existing network services, as well as new virtual network functions. This will enable service chaining between virtual and non-virtual network function and services, – which is a reality in a typical CSP network.
John English made an interesting comparison between the experience the same network vendors have with public cloud environment to that of the current NFV environment:
“In the cloud environment, there’s the potential of a more “fast to fail” situation in which interoperation issues can be witnessed and addressed potentially faster.”
If I follow John’s line of thought, the conclusion that I draw is that putting the blame on the VNF vendors does injustice to the reality. Vendors are driven by market demand. Enabling technology also plays a major role in any big technology transformation, as in the case of cloud.

So the slow adoption of NFV by those same vendors is also attributed to the CSPs complex business processes and long decision-making cycles,   and is intensified by the lack of a simple framework that could be easily adopted and integrated without much hand holding.
As noted in the TMForum survey, orchestration can play a key role in addressing these technology barriers.
Mazin points out, ONAP was born to fill this gap. .
Aligning ONAP more strongly with Kubernetes will accelerate the adoption of ONAP by VNF vendors. A clear piece of evidence that this direction is now gaining  momentum is the work that is done through the integration between ONF and ONAP, as well as the work on Akraino as an edge platform that is already taking big strides  in this direction.

Learning from SD-WAN success

Another way to learn how to speed up NFV adoption is by applying the lessons learned from SD-WAN adoption success on the rest of the areas of the networking stack.
I believe that the key for the success of SD-WAN, was that unlike most of the NFV solutions, it didn’t attempt  to tackle the OPEX issue which is often a slippery slope, with many organizational aspects that makes success harder to measure.
What SD-WAN did pretty well is identify a narrower use case, as well as   more tangible ROI metrics (MPLS vs. OTP), while adding value services (security and such).
The lesson from the SD-WAN experience is that the ability to justify NFV transformation based on the promise of reduced OPEX, is setting the project up for failure. So rather than targeting NFV as a broad organizational-wide initiative, we should target  leaner use cases that have more tangible business value, and expand from there to other areas.

The 5 Key Lessons to Success from Cloudify’s Experience