VNFs, meaning virtual network functions, are important to NFV. Without them there’s no possible business justification to be had, no matter how good our infrastructure or orchestration and management might be. Well, we all know there are supposed to be five stages of grief. I contend that there are five stages of VNF too, and our progress through them—as vendors and as an industry—may decide whether we can forestall the other five stages.
The first stage of VNFs is the billboard stage. In this stage, VNF vendors eagerly seek publicity and in many cases do that by linking themselves to any vendor who can spell “ecosystem” (even if they get a few letters wrong). The reason for this is fairly obvious; VNFs can’t deploy except as a part of a broader NFV ecosystem and it’s far from clear early on who the winners in that space might be.
Most VNF providers are in the billboard stage now, and they’re there because there’s little barrier to being a partner to the NFV masses and little they can do to get traction except as a part of either an NFV trial or a larger RFP. Most will probably never get out of this phase, because the primo players at the ecosystem level aren’t interested in a cattle call, they want offerings they can justify integration and trial efforts on. Many are called but few are chosen here.
The second stage of NFV is the see-what-sticks phase. A VNF vendor enters this phase, typically from the billboard phase, when they start to understand that real engagement is going to involve a significant commitment of resources to every “ecosystem partner” they think has a shot. Since most probably won’t qualify, this phase is really about weeding out the chaff so you can focus on the few great ones.
This is the phase where a vendor typically learns the details of operationalizing NFV, and the way those details will impact VNFs. In many cases this will generate a significant amount of new development. In some it may bring relief. Some VNF vendors will realize that their “success” depends less on an ecosystem partner than they might have thought because the nature of their product (part of a business services vCPE chain, for example) allows them to deploy with little or no real NFV linkage. Those VNF vendors will wait here a while as things develop on a broader NFV front.
Stage three is the ride a magic bullet phase. Here, VNF vendors discover that NFV opportunities that seem real are focused on a very small set of services, justifying a small set of VNFs. Right now, for example, the two magic bullets are mobile and business-related vCPE. IoT could be added. Where a VNF vendor happens to have such an offering, this offering now becomes the Road to the Promised Land, and (mixing a few metaphors) they’ll forsake all others to get their key VNF or VNFs buffed up and ready.
Some vendors, of course, won’t be that lucky. For that group, the only hope is to find some connection between what they can do and the key opportunity drivers that are emerging. Security, application acceleration, and even collaboration players will all want to make their stuff look like a part of the magic bullets being recognized. Most won’t make a decisive connection.
Stage four is perhaps the most critical of all the NFV stages, the second effort stage. It’s not that we’re asking VNF vendors to have another desperate run at the goal, but that this is the stage where everyone at every level recognizes that one magic bullet doesn’t win a war. NFV has to be broad-based to gain enough in benefits to justify the enormous industry effort.
This is where NFV gets real, because it’s relatively easy in the current immature world of NFV specifications and implementations to make a single VNF work. The question is whether you can do two, and this is the stage where that has to happen. Most operators say that they’re going to expect a pathway to their second VNF about the time they start field trials on the first, and that they’ll be looking for the features that make their NFV solution inclusive during those trials.
Which brings us to stage five of VNFs, which is reckoning. Every VNF vendor who manages to get to stage four won’t move on, in no small part because many will have hitched their wagon to the wrong star, focusing on an ecosystem that doesn’t have the breadth. The big question for the industry is whether enough VNFs pass through this stage without washing out. Every NFV trial, every ecosystem, won’t succeed but I suspect that if the odds aren’t way better than 50:50 even in the early stages, there’s going to be a lot of blowback.
If you’re a VNF vendor, you need to be looking at the stages one or two ahead of where you are, at the least. The most critical stage of all, IMHO, is stage three, where VNFs will have to prove not only that they partnered with the right ecosystem vendor(s) but also that they’ve envisioned a lively market opportunity in which their VNF can play. Next-most-critical is stage four, where a VNF provider with one story figures out that they need two good ones at the minimum.
The obvious question is where we are, stage-wise, and it’s difficult to answer that. Every provider of VNFs has an independent vision and program, though maturity of both vary considerably. My rough surveys suggest that two-thirds of all purported providers of VNFs have little other than a hopeful eye on the future. One told me that “VNFs are aspirations not products”, citing the fact that there was only an immature vision of deployment.
Of the third who actually have something, the two focus areas are vCPE and mobility/IMS/EPS. There is a pretty solid business case for agile mobile infrastructure, even out to cloud RAN or CRAN. The interesting point is that mobile infrastructure is more a cloud application than an NFV application; the specifics of NFV are really not needed to justify early deployment and make a business case. The problem is that it might be difficult to develop a second act from a pure-cloud vision of mobility. Other apps require more dynamic deployment and management, and thus depend more on NFV.
vCPE is also knotty in terms of its ability to pull through full NFV. The “edge-hosted” model offers some benefit versus standard hardware, and like mobility is could stand alone (in this case, as an agile-edge application set) without much real NFV involvement. Again, the challenge would be in transitioning it to a broader opportunity base. The edge features of business services are not themselves highly dynamic, and once you’ve deployed what a customer is willing to pay for, might a custom device that’s operationally simpler be a better approach? We don’t have enough data to determine that right now.