It isn't hard to find folks who'll say telecom's adoption of NFV isn't going all that well, but few speak with the authority -- and specificity -- of veteran industry analyst Tom Nolle.
Nolle, a software architect and head of his own consultancy, CIMI Group, was closely engaged with operators and vendors in the early days of Network Functions Virtualization, and as the leader of a consortium called CloudNFV, had the first proof-of-concept to be approved by ETSI's NFV Industry Standards Group.
What Nolle now says, however, is that the industry made a fundamental mistake in adopting what was intended to be ETSI NFV ISG's initial functional model as its actual software implementation for NFV. In doing so, it sent NFV development off in the wrong direction -- an error from which the industry hasn't recovered.
"People constantly assured me it was only a functional diagram and wasn't intended to show how the software would really be structured," he says in an interview. "I told them from the very beginning that if you did structure the software that way, you would produce something that isn't going to work and that's exactly what happened: We produced something that isn't going to work on a large scale."
"The fundamental issue here is we should have known that this has to be a data model-mediated, stateless process-implemented framework for the cloud, or it is not going to scale," Nolle states. "And that is the reality of this."
Spelling it out
In a blog posted earlier this week, Nolle lays out how the original CloudNFV approach addressed critical issues still being raised today around NFV, and he is confident in saying he believes it would have worked.
"If we could have done what the architecture was intended to do, I believe that by the early part of 2014, we could have had a global multi-operator testbed for full orchestration of management and operations process and onboarding of VNFs in a way that would have been standardizable, repeatable and everything," Nolle says. "I believe that because I sat down with six operators and showed them through the process how it worked and they agreed it would work."
For those who don't remember CloudNFV, it was a small pack of vendors, led by Nolle, that argued NFV would require a cloud-based implementation. The group set about developing a prototype as quickly as possible, which became the ETSI proof-of-concept, sponsored by Telefonica and Sprint. The intent was to move quickly to productize, but the six vendors involved never took that final step. Nolle stepped away from the project in early 2014, having spent more than a year of his own time on the effort. (See CloudNFV: Dell's Lost Opportunity?)
"It ended because ultimately it was a small consortium activity that never had the kind of funding it needed to have, and where the goals of the individual companies to make a profit from their efforts eventually made it impossible to move forward collectively," Nolle says now.
But he is frustrated looking back, because NFV has pretty much evolved as he feared it might. Nolle is known for his candor -- and his amazing safari vacations -- and isn't pulling any punches now. Five years into its evolution, NFV hasn't been the transformational technology the industry sought.
"I'm frustrated because I'm saying to these guys right from the start, hey, this is a cloud development process, where is the discussion of the cloud architecture?" he comments. "Where are the issues being raised that define how this would be made to be scalable and resilient and so forth? These are all things that a software architect would say are part and parcel of the value proposition, that you need at the start because you can't retrofit a new programming architecture onto an old set of interfaces, but we never did it."
There has been an evolution in the cloud realm, but it's being led by Amazon, Google and Microsoft, he notes. They are now producing programming languages and software architectures that deliver on the promise of cloud, supporting event-driven applications.
"That is what NFV would look like if you generalized it. It's an event-driven application where events are service conditions," Nolle says. "All event-driven applications are going to end up being written this way. It's the only way you can write them if they are going to work properly."
Is it too late to start over?
The veteran analyst says it's not impossible for the right approach to NFV to still be adopted, but he sees that as unlikely for a couple of reasons. First, it would mean companies basically throw away a ton of work they've already done and that's going against their internal politics in a big way. Secondly, Nolle sees some operators embracing a different strategy: buying legacy stuff more cheaply.
"The biggest problem is tempis fugit," he comments. "There was a compelling value proposition for NFV in 2013 -- that value proposition is rapidly diminishing because the more operators invest in another model of network transformation, a model that says, screw virtualization and all the other things, let's just buy really cheap stuff. And the more you invest in really cheap legacy technology models, the less incremental value there is to the original NFV concept."
Nolle believes much of what is called NFV today is basically replacing a physical appliance with a general-purpose computer and some software instances.
"The result is still a box -- it has none of the dynamism or resilience is baked into the process," he says. "I've just taken logic that used to run in a box and run it in a different box, or done it a cloud-hosted services."
For a look back at CloudNFV:
- Answering the NFV Management Challenge
- NFV in the Cloud: It's Complicated
- Building NFV on the Best Thinking
- Top 5 NFV Movers & Shakers
- NFV Takes Center Stage for TM Forum
- MWC Offers Peek at NFV Projects
- Dell Has Big NFV Plans
- Analyst: Transformation Must Be Top-Down
— Carol Wilson, Editor-at-Large, Light Reading