SDxCentral
Join Log In
SD-WAN 4 5G 17 Edge 7 IoT 14 SDN 9 NFV 10 Containers 2 Cloud 15 Security 5 AI 8 Data Center Storage 1 APM/NPM 1 Open Source

Log In to SDxCentral

Log in with your email? Forgot your password?
  • Newsletters
  • eBriefs
  • Podcasts
  • Webinars
  • Videos
  • Directory
  • White Papers
  • Resources
  • Use Cases
  • Support

Join SDxCentral and get information tailored to your particular interests everyday.

Join
Sponsored:
Dell EMC 8 Citrix Riverbed

Openness Is the True Path of NFV

Openness Is the True Path of NFV
Nati Shalom January 2, 2017
9:00 am MT

A recent SDxCentral contributed post asked, “Does NFV create vendor lock-in?” In it, author Shehzad Merchant posits that the current trajectory of network functions virtualization (NFV) is headed down a path of tighter vendor lock-in by virtue of “the use of specialized acceleration engines and network interface cards (NICs) for performance improvements within the server plus the use of dedicated, stateful load-balancer appliances to distribute traffic across servers.”

I applaud Merchant for raising the issue, but the important issue here isn’t the one he raises. Rather, the important issue is this: lock-in with NFV derives from proprietary solutions. Openness is the true path of NFV. It’s already happening. Here’s why.

We’re From Cisco, and We’re Here to Help You

First, the lock-in Merchant speaks of results from hardware vendors’ inherent conflicts of interest. They are biased toward promoting their own proprietary hardware extensions under the guise of “openness.” In direct contrast, let’s look at pure-play, open source options. Network operators have choices in orchestration and virtual network functions (VNFs) including (Cloudify, Clearwater, etc.) where openness is core to the model. When you look at the market from these two diametrically opposed views, you can begin to see how the open example promoted by AT&T is one that proprietary vendors like Cisco cannot follow.

Want Portability? Look Up the Stack

Next, we need to reevaluate our understanding of portability. Or, to use a worn-out business phrase, we need to “shift our paradigm.” To achieve portability, we need high-level abstraction—that is, abstraction at the orchestration level rather than the infrastructure level. The open-source Cloudify project offers examples that demonstrate how to achieve portability, not just between different infrastructure providers, but also between different software stacks.

You Say ‘Turnkey,’ I Say ‘Lock-In’

The allure of single-vendor, turnkey solutions is seductive. It’s also the road to lock-in, because you become increasingly dependent on a single vendor to develop, ship, and support every feature (or most of them) in the stack—regardless if the stack is open source or proprietary. Merchant misses this key point, as (paradoxically) do writers who think open source automatically reduces lock-in.

Making Open… Open

The open source alternative to proprietary NFV solutions requires a different engagement model between vendors and operators. Primarily, this means a partnership model that looks more like a joint venture relationship with the vendors that are part of the solution. This means that the carrier (or enterprise operator of a large, distributed network) needs to be part of the solution and not just the one that defines requirements for vendors. This isn’t as hard as you might think: there are growing numbers of open source solutions that can fill in the stack.

To help get you started, here’s a dirt-simple “openness” checklist:

  • How simple is it to integrate new stacks/services without involvement from the vendor?
  • Can I install or customize the solution for free without vendor involvement?
  • Can it work with different clouds/infrastructures?
  • Will it integrate with other—potentially competing—products?
  • Are the open source projects on which it’s based supported by an active community where decisions are made inclusively via an open governance process?
  • Does it support commonly accepted scale-out networking standards like topology and orchestration specification for cloud applications (TOSCA) and YANG?

If vendors pass these tests, you’re off to a great start.

“Turnkey by Default” is the Problem, not Openness

The NFV solutions Merchant is talking about fail to deliver a true open solution. I argue that the reason for this is that customers are voluntarily locking themselves in by asking for turnkey solutions, which lead them to lock in by default. To achieve a true open NFV solution, carriers must first embrace a best-of-breed approach, working with vendors offering business models that don’t conflict with their anti-lock-in needs.

Perhaps the question Merchant raises, “Does NFV create vendor lock-in?” should be modified to “Are carriers really ready to commit to an Open NFV strategy?” Because if they’re ready to change old habits, they can get an open solution that puts them in control, not their vendors.

Related Articles

Containers in Telcos – Are We There Yet?
Containers in Telcos – Are We There Yet?
AT&T 5G Airship Plans Powered by Mirantis
AT&T 5G, Airship Plans Powered by Mirantis
AT&T’s Extensive SDN Plans Pave Way for 5G
AT&T’s Extensive SDN Plans Pave Way for 5G
SD-WAN-There’s-Nothing-Universal-About-the-Universal-CPE
There’s Nothing Universal About the Universal CPE
ONAP Casablanca Shows Up in ‘All the Gin Joints’
ONAP Casablanca Shows Up in ‘All the Gin Joints’
CenturyLink Dove Into NFV Early Because of a Profitable Business Case
CenturyLink Dove Into NFV Early Because of a Profitable Business Case
SDxCentral Daily News

Join your Peers! Subscribe to SDxCentral's Newsletter

Article Tags:

Contributed Articles NFV Open Source VNF

Subscribe to Get the Daily News!

About SDxCentral

  • Newsletters
  • About Us
  • Contact Us
  • Work With Us
  • Editorial Team
  • Careers
  • Legal
  • Support

Engage With us

This material may not be copied, reproduced, or modified in whole or in part for any purpose except with express written permission from an authorized representative of SDxCentral, LLC. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. All Rights Reserved.

© 2012-2019 SDxCentral, LLC, All Rights Reserved. SDNCentral™, the SDNCentral logo, SDxCentral™, SDxCentral logo, SDxNews™, SDxTech™, SDx™, the SDx logo, and DemoFriday™ are trademarks of SDxCentral, LLC in the U.S. and other countries.

  • Terms of Service
  • Privacy