Open SDN: The fine line between progress and vendor lock-in

Within open SDN, there are two dynamics: trying new things and avoiding lock-in. Michael Bushong explains the area between progress and lock-in.

Although the definitions are a bit murky, the trend is clear -- SDN is coming. And along with it comes the promise of layered architectures, automation and intelligent networks, all within an open SDN, heterogeneous environment.

It's the last part -- a heterogeneous environment -- that is driving one of the major SDN undercurrents often referred to as open SDN. Network architects are demanding that SDN solutions avoid the stench of proprietary, allowing them to cobble together architectures that are composed of elements from different vendors. The goal here is not to have a piecemeal network, but rather to avoid the longer-term costs (both financial and technological) associated with vendor lock-in. To the extent that individual components can be replaced by functionally equivalent products from other vendors, lock-in can theoretically be minimized.

Or can it?

If open SDN requires standards, can we afford to wait?

Most of the dialogue around open SDN has focused on the rise of standards-based protocols, such as OpenFlow. The justification is that by standardizing how elements talk to each other, the boundaries between system components will be common -- and this rationale is sound. Standards have been critically important in networking to date; without protocols such as Open Shortest Path First and Border Gateway Protocol, designing a functional network would be near impossible.

But if there is one thing that standards have taught us over the past three decades, it's that the standardization process is painfully slow, sometimes bureaucratic and frequently tinged with hints of corporate agenda. The protocols that have become staples in virtually every network on the planet emerged over decades, not months. The question is whether or not that glacial pace will be fast enough to keep up with the demand behind SDN.

To be fair, the Open Networking Foundation -- the body driving the OpenFlow standards -- has been remarkably more agile than other standards organizations. In just a few years, the OpenFlow specification has evolved from a science project to something that's commercially viable. But SDN is broader than just OpenFlow. It relies on controller architectures, application programming interfaces from those controllers to controller applications, and abstractions between those applications and the vast pool of end-user applications.

So what's the networking ecosystem to do? If the entire industry waits for the various pieces to be picked up and addressed, the vision of a vast, software-defined network built from gear that spans the vendor landscape will be decades away.

The reality is that SDN is an emerging set of technologies. It's not obvious which technologies will or should succeed, and we won't collectively know without real-world experimentation. Success cannot be determined on white boards, in PowerPoint and in text files detailing specifications. Some issues only surface in production environments operating at scale, and we need the experience to test, learn and iterate.

But how does a vendor try new things if they are obligated to adhere to a pre-existing standard? The answer is simple: They can't.

The myth of vendor lock-in as evil

There are two conflicting dynamics: the demand for a new way of doing things and the desire to avoid lock-in. A new way can't come without people forging their own road, but in doing so, they will naturally create varying degrees of lock-in. This is going to force customers to choose which is more important to them: progress or lock-in?

The truth here is that lock-in is not inherently good or bad. It merely is. If the capability that a solution provides drives enough value, the lock-in issue is far less important. If, however, the solution doesn't drive meaningful value, lock-in can be crippling. Understanding this is the key to how customers will need to navigate the emerging SDN landscape.

SDN standards

XMPP becomes a southbound SDN protocol

Are PCE and SDN connected?

How big data comes into play with SDN

Open vSwitch integrates into the OpenDaylight controller

How customers choose to manage this change will depend largely on the type of network they want to run.

For customers who are particularly sensitive to vendor pricing, lock-in can have devastating effects. A standards-based SDN approach makes perfect sense here, even if it takes slightly longer to fully emerge. However, these customers should be aware that there will be additional integration challenges; cobbling together architectures that represent a mosaic of vendor offerings will likely prove more difficult than many expect.

But the end result will provide flexibility that likely can't be matched by a single-vendor solution. Customers who already lean toward programmable infrastructure (as with DevOps) will tend to find this transition easier. The challenge can also be somewhat mitigated by selecting equipment that is designed with this type of integration in mind.

For customers who are more interested in ease of deployment or who are targeting a specific capability, single-vendor solutions will likely be the path. When vendors offer a complete solution, the burden of test and integration is theirs to bear. Additionally, non-standards-based approaches will have a bit more flexibility in incorporating new approaches and technologies, potentially offering greater value through unmatched capabilities.

Ultimately, the market will likely be split in how they adopt SDN. But given the varied views on everything from definition to architectures thus far, this probably comes as no surprise.

Dig Deeper on SDN network virtualization

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

As the Executive Director of the Open Networking Foundation, I want to respond to this article and to its perspective on vendor lock-in. ONF feels strongly that accepting vendor lock-in to “keep up with the demand behind SDN” does not benefit end users in the long run – it benefits vendors. If we are truly focused on moving SDN forward, with the needs of the end users in mind, we need to be open about the pitfalls of lock-in and the benefits of Open SDN. Lock-in implies lack of choice and typically results in less innovation and higher prices. It is natural for vendors to offer non-standard solutions before standards stabilize, but deliberate vendor strategies to create lock-in impede the demand for and completion of standards.

ONF is championing the Open SDN movement by bringing together more than 100 member companies to establish standards and encourage interoperability. Through programs and events including our OpenFlow Conformance Testing Program as well as ONF PlugFests, vendors can ensure that their products comply with industry standards and interoperate with other products, respectively. These activities serve consumers by protecting their interests, and they serve vendors by making their products attractive to customers who want to avoid lock-in. Frankly, the whole premise of open interfaces reduces the likelihood of vendor lock-in. Indeed, the very nature of software-defined networking built on an OpenFlow substrate fosters creative, customer-specific (and even vendor-specific) solutions implemented in software and readily modified and improved, avoiding vendor lock-in.

As this movement progresses, we can turn our focus to addressing the demands of end users, or we can focus on the interests of vendors; in ONF we have chosen the former. We don't see any merit in vendor lock-in, which should be viewed as always undesirable and usually avoidable. – Dan Pitt, Executive Director, Open Networking Foundation
Cancel

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close