BETA
This is a BETA experience. You may opt-out by clicking here

More From Forbes

Edit Story

The Collision Of Open Source, Open Networking, And SDN

Following
POST WRITTEN BY
John Fruehe
This article is more than 8 years old.

Open source is well understood in the software world, as it has helped accelerate IT and bring business advantages by accelerating new solutions and lowering costs—especially around cloud computing. Open networking and software-defined networking (SDN) both promise to bring the benefits of open source to the world of networking, but is this something that your company can benefit from now? When we talk to customers (and even those in the industry), there is a general sense of confusion about what “open” means in terms of networking. There is of course open source in the world of networking, along with an explicit open networking movement that is about opening up the solutions, but not necessarily giving them away as open source does. Then to add one more ingredient to the idea of “open” in networking, software-defined networking (SDN) comes along to “open up networking”. Great, now most customers are confused.

As vendors like Cisco Systems , Dell , Hewlett-Packard , Intel , Juniper Networks , Microsoft , VMware , and others all try to position their products and strategies the waters get murkier, as everyone says open but has a different perspective. Being “open” is a big benefit in the world of closed network ecosystems. But as many are finding out, open means different things to different people. If Potter Stewart were still alive he’d probably say, “I can’t describe ‘open’ in networking, but I know it when I see it”.

Taking a look at the three major categories, you’ll see plenty of overlap in the Venn diagram. Things can be open source but not open networking. And just because something is open networking does not mean that it is open source. Most importantly, being software-defined could be both or neither. But the hardest thing to find is something that is truly open source and truly open networking and truly software-defined networking (OpenContrail is probably the closest example).

Open source generally refers to software or hardware that can be freely used, changed, and shared either in a modified or unmodified manner. Typically, this conforms to an open source licensing (like GNU or Apache ) where the user accepts some limitations or restrictions in order to use the product without having to pay royalties. Linux, for instance, is built on open source code that is freely contributed; companies like Red Hat will provide the software at no charge (as in Fedora) but then will have a business model that charges for support, not software. In the networking world, things like Juniper Networks’s OpenContrail fall into this category. The OpenFlow protocol is an example of a pervasive open source component of networking, but this is a protocol, like Ethernet, not a product per se. OpenFlow is supported by a large number of companies, and each uses it exactly the same way. But just because an application uses the OpenFlow protocol does not mean that the application is open source, and as a matter of fact even some very proprietary networking stacks support OpenFlow.

Open networking does not require open source; it is simply breaking some of the tight connections between hardware and software. Traditionally network equipment was sold as a tightly coupled “black box” with the hardware and network operating system integrated together. Customers had no way of separating these, nor the inclination to do so until they wanted to decentralize some of the control.  This caused headaches because there was no flexibility, and the black box limited customer innovation. Open networking splits the solution, allowing a network OS (or virtualization layer) to be installed on almost any networking hardware (or even server). This “opens up” the stack, allowing companies like Big Switch Networks, Cumulus Networks, or Pluribus Networks to sell their advanced software products without having to be in the hardware business. Even though they are often based on Linux, these network operating systems are not necessarily open source. And on the hardware side, vendors like Accton, Dell, Hewlett-Packard, or Quanta can provide the platforms without being in the OS business (even though most do provide their own network OS option as well).

Software-defined networking (SDN) is a decentralization that splits the control plane from the forwarding plane, allowing for network control to be distributed closer to the workload. This is where a great amount of confusion exists. SDN relies heavily on the open protocol OpenFlow, but the software is generally not open source. And while SDN does allow for open networking (and allows for applications to be run on hardware switches and servers), it can be done in a more limited environment as well. Cisco Systems’s ACI is software-defined but is designed to run primarily on Cisco Systems hardware. VMware’s NSX will run on a variety of platforms but is really optimized to live primarily in a VMware virtualized world. Neither of these is necessarily a bad thing, if they match a customer’s needs, but it does cloud the water a bit when people talk about the open nature of SDN. While it is opening up control, it does not necessarily need to do it with open source or open networking.

As the network continues to evolve and businesses see their infrastructure transform, we’ll definitely see more of these open options coming to market. But as vendors bring new products to market and tout “openness”, just remember that not all that is open is equal...or even close to being equivalent. It is best to understand what your needs are first before heading down that path.

Disclosure: My firm, Moor Insights & Strategy, like all research and analyst firms, provides or has provided research, analysis, advising, and/or consulting to many high-tech companies in the industry, including Cisco Systems, Dell, Hewlett-Packard, Intel, and Microsoft cited in this article. I do not hold any equity positions with any companies cited in this column.