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.