Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Openness Is the True Path of NFV

DZone's Guide to

Openness Is the True Path of NFV

Are you afraid of getting extended into lock-in with vendor-specific NFV? Good for you. Be on the lookout for double-speak that leads you down a narrow path to lock-in.

· Cloud Zone
Free Resource

What if you could learn how to use MongoDB directly from the experts, on your schedule, for free? We've put together the ultimate guide for learning MongoDB. Sign up and you'll receive instructions for how to get started!

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 failing 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.

What if you could learn how to use MongoDB directly from the experts, on your schedule, for free? We've put together the ultimate guide for learning MongoDBSign up and you'll receive instructions for how to get started!

Topics:
cloud ,nfv ,vendor lock-in

Published at DZone with permission of Nati Shalom, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}