How do vendors and network operators solve their NFV problem? In just the last two or three months, it’s become clear that operators are generally of the view that NFV, at least as ETSI has defined it, has limited value. It’s clear that carrier cloud has enormous value, but both vendors and operators are struggling to bootstrap their way into it, or even to define its architecture. NFV has years of standards-group momentum, media attention (even if it’s shifting in a negative direction) and at least a constituency. More, for sure, than “carrier cloud” has. What now?
There are three options that seem to offer themselves for everyone who was in the NFV camp:
- Stay with NFV both as a term for a hosted-feature future and as a vehicle (through the ETSI NFV ISG) for developing carrier cloud. This is the “stay the course” track.
- Stay with NFV as a term, but follow the hallowed industry practice of taking a popular name and giving it to anything that happens to be even slightly related to the original concept, but more useful and likely to succeed. Then go ahead and let an open-source movement gradually do the right thing, all the time calling it “NFV.” We’ll call this the “subduction” track.
- Let the term “NFV” continue to apply to what it does today, but “superset it”, creating a higher-layer concept like “Cloud Network Functions” or better yet, “Cloud-Native Functions” (CNF) that then kicks off a rational cloud-native function effort, eventually absorbing ETSI NFV as a special case. This is the “superset it” track.
Starting from the top, the stay-the-NFV-course camp has a lot going for it. Yes, it’s true that the ETSI efforts have gone way off track. Yes, it’s true that the media (who has to make everything either a positive revolution or a cynical fraud) is turning on NFV. The ISG still exists, there are some in it who can see the value of shifting future activity to either correct the flaws of the past, or at least add a layer that includes both the old and the right approaches.
For operators, this might be the most dangerous of the options. CFO and CIO support for NFV has been lukewarm from the start, and the only trends I see only lessen that support. I’m also seeing a lot of questions being asked by the CTO organization whose standards people have been involved in the ETSI ISG. Finally, it’s been five years since the ISG started and they’ve been exposed to the perspectives that the NFV structure was wrong for all that period. Nothing happened for all that time, so we have to assume that there’s a lot of inertia to still to play out here.
For vendors, all these issues apply and then some, but ironically, they push vendors in the opposite direction. Vendors are about sales, about buyers. We have lab trials and deployments on NFV. NFV could be linked, at least semantically, with things like 5G and IoT. NFV could in theory be applied to anything that requires hosted elements. There’s a constituency, a familiarity, in NFV, and you can’t sell anything if nobody is designated as a buyer. Carrier cloud, or cloud-native, is a better idea with little or no specific sponsorship, no architecture to define it, no specific service driver.
The subduction camp says “Well, network functions virtualization is after all about virtualizing network functions. Isn’t a cloud-hosted function virtual? Who says the term has to mean ETSI ISG NFV instead of just NFV? It’ll all come out in the end, and the ETSI ISG people are working on the problem of function virtualization, while the cloud people are working on…well…cloud. Let the kids play.”
Operators like this approach best for a bunch of reasons. First, it validates an enormous sunk resource effort in the NFV ISG. Second, it validates all that management support for NFV. Third, they can cite open-source as the revolutionary force that converts NFV into cloud-native. “Open-source” means “someone else is doing it for free” to many operator executives. They’ll sit back and the right answer will manifest itself (to quote Emerson) “in silence and certainty”. This should have been what was done from the first, some already think. Operators can be even less involved than with the ETSI NFV ISG.
We can see some indicators of this perspective already. All of a sudden, we have a looming bandwidth glut, excess capacity that somehow operators need to monetize. There’s no profit per bit problem, there’s a lack of sufficient demand. New applications like autonomous cars, IoT, augmented reality, and so forth will take up the slack, creating zillions of new connections and connection service revenue dollars. So the story goes, at least.
Vendors also favor this approach, because it combines the positives of the stay-the-course option with a theoretical pathway to actually doing something useful. Since “NFV” like most buzzwords was valued by vendors mostly to open the door for sales calls that could then shift focus to something near-term and practical, a theoretical path is just as good as a real one. Better, because the vendors might have to support a real one, while for a theoretical one, a nice press release will do.
The right answer, of course, is our third camp, the “superset” approach. In every respect, NFV was too narrow a concept to be a revolution, or even to justify the enormous amount of resources put into it. What should have been done is to explore the requirements for carrier cloud, the broader hosting mission that would have to cover all the bases for new services to be offered by operators down the line. NFV is surely a part of that (a small part, overall, representing only about 5% of the total opportunity in its best year, which is 2025 in my model), but not enough in itself to move the needle on infrastructure spending balance.
The challenge with the superset approach is getting a forum. Not only do you need some body to organize the process and actually shepherd things toward the goal, you need a bully pulpit to sing the praises of the concept and raise both operator and vendor awareness. Good ink, as they say. The first of these flies in the face of how bodies want to work these days; microsegmentation is the name of the game. Pick a small target and show early results. “God-boxes” were anathema to VCs in the old days because they didn’t have a strong focus. Think of something driven by six or seven major opportunity forces, implicating software, servers, and networking. How “god-boxy” could you get?
All the difficulties aside, the carrier cloud challenge is really just that broad, which makes it all the more important to somehow come up with a single strategy that answers all the opportunity requirements. I think it’s going to be very difficult to get to the superset future through any form of standardization or open-source activity. We’re probably going to blunder there through a combination of operator efforts to deal with the multiple parallel drivers of carrier cloud and vendor desire to get a lock on early deployments. That’s going to take a lot longer than it should. We could have been at the point of about 2500 new carrier cloud data centers by now, and we’re actually less than half-way there.