NFV Is Revolution, Not Evolution And Open Source Will Be The Spark

It’s not news that the networking industry is in the early stages of a major disruption driven by network functions virtualization (NFV) and software-defined networking (SDN). But make no mistake; this is not an incremental, evolutionary thing. Sure, the term, “disruption” gets thrown around a lot but this really is one of those rare moments in time where an entire market will get re-organized. It will create tremendous opportunities for new and innovative companies that aren’t afraid to do things differently and take on some very well established vendors.

Open source software will disrupt the networking world even faster than it has disrupted the enterprise software and cloud services industries.

Now, if you spend a lot of time reading the trade press and analyst reports, you’d say I’m being hyperbolic. Or naïve. Perhaps both. Well, I read the same stuff. It’s very safe to say that this is “evolution, not revolution”. It’s easy to say that NFV is an incremental technology advancement that will mature over seven to ten years. It’s also fun (and lazy) to mock the whole thing as nothing more than marketing hype and techno-marketing speak. But I’m confident that things will be different. Why? Because we have the lessons learned (and still being learned) by the enterprise technology vendors that have had their business models completely disrupted by open source software and emerging cloud players. We only need to apply them to NFV.

The truth is that NFV is at a very similar point in its trajectory that virtualization was about a decade ago:

Automation/Scale Maturity Model

That is, it’s very early. Maturity models are nothing new and developed this based on our experience and countless customer conversations. The premise is simple. First you virtualize, then you automate, then you scale. The last level, which not everyone will aspire to, is to deploy dynamic cloud-based network services.

Today, most network product builders and service providers are focused on simply virtualizing physical network functions. This neatly parallels server virtualization, which was in the same place about ten years ago. At that time, systems administrators and developers were just trying to run test and dev environments or port an application to a single virtual machine. It took time before VMware vMotion and management tools matured to enable automation, orchestration, and broad data center roll out. Similarly today, only a few carriers/service providers have advanced to level 2 where they’re attempting to orchestrate virtual network resources, build some level of automation, and deploy on standard cloud infrastructure. Few, if any, are even thinking about auto-scaling, multi-VM VNFs, and cloud-based network services. There are many valid reasons for the early fits and starts, but there are some commonalities that are acting as headwinds:

Evolving specifications and implementations

Standardization drove the takeoff in enterprise data center virtualization and cloud services. With NFV, there are standards but each vendor has their own proprietary implementation. The ETSI NFV reference architecture and NFV MANO architecture are painted in broad strokes that are open to vendor interpretation and extension. In fact, the largest carriers are attempting to build their own orchestration platforms. This is mostly due to a lack of suitable vendor offerings – Axel Clauberg of Deutsche Telekom referred to it as a “zoo of orchestrators” – but also because carriers often believe they must build their own to create differentiation and early-mover advantage. However, if every carrier builds a unique platform, even if using multiple “open” standards, they’ll have the added burden of integrating multiple point solutions onto their platform and B/OSS. It will also inhibit the growth of a vibrant ecosystem since VNF builders will have a much harder time building and maintaining solutions for multiple walled gardens.

Trouble understanding what “open” really means

There are multiple open source and pseudo-open source initiatives that each tackles a component of SDN/NFV and cloud management. OPNFV, Open MANO, OpenDaylight, OpenStack, Open vSwitch, etc. are the big examples of individual open source components that need to be stitched together. This liberal use and extension of open source components and integration among the various layers lends itself to a new kind of vendor lock-in. Every vendor it seems is marketing their solution as “open”, but peel back the onion and it’s difficult to understand what “open” truly means.

Today, in regards to open source, we’re seeing something very similar to what happened in 2008 when cloud services like AWS were emerging as mainstream. At that time, every hosting and managed services provider added the word, “cloud” to their offerings. This became known as “cloud washing”. Legacy technology vendors are using the same tactic in response to the explosion in popularity of open source software – call it “open washing” for lack of a better term. Using open source components doesn’t mean the software or platform is truly open. And everyone should be skeptical of “open” APIs that are still proprietary. As an example, even though today there is a “zoo of orchestrators”, the descriptors that these orchestrators use are mostly proprietary.

It’s really hard

Obvious, I know. Fearing vendor lock-in and seeing no industry consensus on a customer-centric, open source platform, it’s not surprising that carriers are proceeding along without one. But for all the reasons I just mentioned and some I haven’t, it’s not a simple task. Building a scalable network service that can run on COTS infrastructure while maintaining SLAs is not trivial. In addition to the above, horizontally scaling a virtual network function across distributed servers, data centers, and clouds is worlds apart from adding line cards to a box. It requires new levels of orchestration, automation, and integration. Solution architects could write an entire blog on the technical complexities. NFV, as it stands today, is trading one complexity for another.

Even with all that, I’m still confident that NFV is more revolution than evolution. And the reason I believe that is because open source software will disrupt the networking world even faster than it has disrupted the enterprise software and cloud services industries.

Think about this. VMware started in 1998, was acquired by EMC in 2004 for $500 million, and today is worth about $38 Billion. That’s a pretty quick ride to that valuation. Uber, however, was founded in 2009 and is now estimated to be worth about $40 Billion. Nest Labs was founded in 2010 and acquired just four years later by Google for $3.2 Billion. Those are just two examples of innovative customer-centric companies using software to upset an entire industry. And the underlying catalyst that enabled the creation of these companies and fueled their rapid growth were developer communities building a common, open source web infrastructure.

The challenge for NFV is that there is no common, open source NFV infrastructure that a developer community can gravitate towards. That’s about to change. introduced RIFT.ware to the world at the Intel Developer Forum in August and will release RIFT.ware 4.0, a complete solution for NFV management and orchestration, to the open source community by the end of 2015. RIFT.ware will deliver a complete, yet modular NFV platform that will make it simple to build, deploy, manage, and scale virtual network functions on any cloud infrastructure. The goal of RIFT.ware is to make the same capabilities and technology enjoyed by the largest networking technology companies available to everyone.

We are optimistic that carriers and service providers will embrace an open source initiative that they can contribute to and use to accelerate their path along the NFV maturity model. We already know that VNF builders, like our partner BENU Networks and others, see the value of a common platform on which to deploy their virtual network solutions – and the value of the platform being open source and available to all. RIFT.ware can be that platform – driven by the end users and ecosystem partners – that standardizes the basic plumbing of NFV and frees carriers, service providers and partners to focus on innovation, scale, and new applications and services.

Want to contribute to the next big thing? The next community-driven, open source infrastructure that disrupts an entire industry? Visit or drop us a line at As we wrote on our web site, “networks have been closed forever. It’s time to open them up.”