I’ve been having some interesting exchanges with operations planners in a couple dozen network operators who have done some NFV deployments. My goal was to see what the issues are likely to be in 2019, and the results were in some cases unexpected. Perhaps the area where there have been the most surprises has been the disconnect between what’s getting reported and what these specialists were seeing.
The area where we hear the most about NFV today is “virtual CPE” or vCPE. The basic notion of vCPE hasn’t changed enormously since 2013 when the seminal end-to-end model of NFV was first developed. CPE is essentially a linear progression of features, including some for security and some for encapsulation. This sequence was called a “service chain”, and it was presumed that the service chain would either be built in the cloud by linking hosted virtual network functions (VNFs) or in a single “universal” CPE device on premises.
Service chaining and vCPE has, according to the operators, been the source of most of the VNF onboarding problems, problems related with converting an arbitrary set of network features into VNFs that can be deployed and managed using the framework described by the NFV ISG. Here are the points operators have made about all of this.
First, operators say that the notion of assembling an inventory of VNFs to create a virtual device is essentially flawed. The presumption is that this approach would let you respond to buyer needs for different feature sets, creating a more agile service. The problem is that the operators with the most experience say that a maximum of five different configurations of features support over 97% of all buyer requirements, and that buyers will typically stay with their first configuration, even when changes to that configuration are supported.
What this adds up to is that it’s easier and cheaper for operators to simply package a couple variant configurations of vCPE software and load one as a unit based on buyer needs. That means that there’s less operational complexity—there is only one “composite VPF” to be hosted wherever you decide to host it. If somebody does want to change their vCPE configuration, you just load a different composite image.
Then there’s the question of how you load things onto uCPE to create vCPE. If you want to follow the NFV rules for deployment and management, you’d need to treat a premises device and a cloud-hosted alternative in the same way, which means that you’d need to use uCPE that looks like an extension of the carrier cloud. That raises a whole new set of operations/management questions because the device is on the user premises. Operators told me that they’d prefer to have some simpler approach to VNF loading, even if it means that they had to use a different process to load up their uCPE versus cloud-host some VNFs.
In the cloud, operators say that service chaining isn’t helpful if you presume that most vCPE is really going to live on the premises. Yes, some operators admit they’ve offered cloud-hosted vCPE features, but they tell me that they’re not selling well and are also not profitable enough to justify a major commitment to the approach.
If you go beyond vCPE, things get really hazy. According to operators, the non-vCPE applications of NFV and cloud-hosted VNFs are getting pulled strongly in a “cloud-native” direction. To most of my operations contacts, “cloud-native” means deployed as it would be in cloud computing, discarding the NFV tools and specifications. They point out that for applications like mobile infrastructure and video caching, the software features are very much like the components of cloud applications, meaning that they’re multi-tenant by nature when NFV has focused on tenant-specific services. Three-quarters of the operators who had any VNFs deployed in such missions admit that they’re not using mandated NFV specifications to guide their deployment and management. Most of those say they are moving even further toward the cloud picture.
The biggest reason for this according to my contacts is that “NFV was designed to build legacy services from hosted components and we need non-legacy services for revenue growth” (to quote one operator). The services operators think will fill their revenue coffers in the future are more like OTT services, which means that they are more likely to need infrastructure resembling that of public cloud providers than like NFV was designed to utilize.
All this comes amidst a general concern that NFV, as a cloud application, is diverging from the cloud. From the first, VNF onboarding has proved much more complicated than expected because the framework for deploying and managing VNFs has continued to evolve away from the way that applications are deployed in the cloud. Unless we want to view the software that’s a candidate for VNF creation as the product of a “VNF industry”, we have to assume that software is part of mainstream development, which means it’s cloud-ready rather than NFV-ready. The biggest problem with onboarding, say the operators, is what they’re expected to onboard to.
None of the two-dozen operators I’ve exchanged views with told me they were dropping NFV, but nearly all of them said that NFV’s success (even in a limited way) depended on reconnecting it with the cloud. Operators are not going to deploy one architecture to deploy and manage legacy service virtualization and another to build OTT service elements that are the primary driver for “carrier cloud” in the first place.
What about things like ONAP and the various open-source NFV platforms? Operators say these are diverging from cloud-accommodating implementations of lifecycle management, which means that they would magnify the problems of cloud-readiness rather than solve them. I’m also seeing increased skepticism that these platforms are developing fast enough to support profitable service deployments, and the longer it takes for that to happen, the harder it will be for legacy-service NFV to resist the pressure of the more cloud-centric and OTT-like applications of carrier cloud.
My models have never suggested any realistic NFV contribution to carrier cloud beyond 2019, and I don’t think any of the operators I’ve talked with believe that ISG-modeled NFV is going to expand much in 2019. If that’s the case, then this may be the year when operators have to start thinking of “cloud-native” in a different, broader, and more serious way.