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.
XMPP becomes a southbound SDN protocol
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.