Why NFV Transitions Won’t Meet Original Timeframes

Software-Defined Networking and the Enterprise

The hype cycle, as the name suggests, is the buzz surrounding a technology. Analysts have made a good deal of money helping people cut through it to understand what is really going on.

In most cases, the reality is that a technology that has generated a tremendous amount of excitement has real possibilities. Just as often, the period between when the technology first becomes known and the point at which it becomes a success is far longer, and has far more twists and turns, than originally thought. It makes sense that this would be the reality since the early days are dominated by marketers and PR folks who have a great interest in extolling potential benefits and no interest in, or even necessarily an understanding of, the challenges.

The hype cycle no doubt is even more complex when the technology is as complicated as network functions virtualization (NFV), the approach that along with software-defined networks (SDN) aims to transition legacy hardware-dominated networks into code-driven, highly flexible affairs that can punch up network capacity, network conditions (such as security and quality of service levels) and applications from the comfort of the corporate office.

That’s the plan, anyway. The road to nirvana is not a short one, however. Light Reading’s Iain Morris suggests that an interim step focused on microservices, which involve knitting applications together out of preexisting building blocks, is increasingly seen as necessary. And it isn’t a slight detour:

But instigating a microservices revolution might be an even taller order than the initial deployment of SDN and NFV. The uncertainty is whether it will roll on naturally from the first virtualization wave or represent another “discontinuity” …

C-level executives are unlikely to hear that the benefits promised them when they signed off on NFV and SDN depend on a previously unmentioned interim generation. Though the business case for SDN and NFV remains strong, it is possible that time to market, cost and other variables could make the overall picture a bit less attractive.

The long(er) road to NFV is a subtext of a post by Heather Kirksey, the director of the Open Platform for Network Functions Virtualization (OPNFV), on the introduction of Brahmaputra, a platform for developing NFV use cases and services. The assumption is that moving to NFV is not easy:

I blogged recently about the role of NFV in this transformation and how the OPNFV project is at the forefront; we’re tasked with creating a carrier-grade, integrated, open source platform to accelerate new NFV products and services. And while the reality of transformation is that it’s a hard, risky and challenging journey, the industry is ripe for change. OPNFV’s second platform release, Brahmaputra, helps set the stage for the NFV ecosystem to start actualizing NFV with a lab-ready framework.

Vendors, such as VMware, which says that its vCloud platform can support more than 40 virtual network functions (VNFs) from 30 vendors, see the big pots of gold at the end of the rainbow and are working accordingly. The point, however, is that this stuff is hard – very hard.

On top of that, NFV and SDN are related but discrete developments. Two simultaneous fundamental transitions most likely are even more complex than simply adding one atop another. The bottom line is simple: NVF and SDN have great potential, but it is unlikely to be realized in the originally projected timeframes.

Carl Weinschenk covers telecom for IT Business Edge. He writes about wireless technology, disaster recovery/business continuity, cellular services, the Internet of Things, machine-to-machine communications and other emerging technologies and platforms. He also covers net neutrality and related regulatory issues. Weinschenk has written about the phone companies, cable operators and related companies for decades and is senior editor of Broadband Technology Report. He can be reached at cweinsch@optonline.net and via twitter at @DailyMusicBrk.