Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Open Source Vs. Proprietary: Time For A New Manifesto: Page 3 of 3

still so unsettled that the lines between open source and proprietary software are even more muddled than with OpenStack. Proprietary networking products invariably use standard protocols and often incorporate open source code -- as the widespread consequences of the OpenSSL Heartbleed bug painfully demonstrated.

The complexity is compounded since the debate happens on four architectural levels:

>> Within the hypervisor and its associated virtual switch, the issue is largely settled. The industry has rapidly consolidated its support for Open vSwitch (OVS) in preference to closed alternatives like Cisco's Nexus 1000V or the virtual switches built into vSphere and Hyper-V.

>> Physical Layer 2 switching and flow control. Here the debate centers on OpenFlow and whether a hard separation between physical network data and control planes is necessary, and the pros and cons of replacing conventional switch fabrics using integrated (and closed) software with a central OpenFlow controller. As we point out in our SDN: Physical vs. Logical report, OpenFlow deals with physical network devices and ports and the flows among them. However, as more IT workloads become virtualized, an increasing percentage of data center traffic is initiated by -- and flows among -- virtual ports and switches. And in the virtual world, you don't need OpenFlow to get the benefits of a software-defined and automated network. And don't let vendors conflate the two.

Aside from the question of whether OpenFlow is even necessary in enterprise data centers, Network Computing contributor Ethan Banks points out that its "openness" is nuanced because the standards process is actually closed, even though the results are public.

>> Layer 3 virtual networks. This is still the Wild West of technology, with abundant choices, no clear winners, and competing architectures: one using virtual overlays to an Ethernet fabric substrate, the other relying on an OpenFlow controller to manage all layers of the network stack. The most widely known, if not yet popular, overlay is VMware's mostly proprietary NSX.

We say "mostly" because NSX does use OVS and standard tunneling protocols, such as VXLAN, STT, and NVGRE. However, as we discuss in depth in our Network Computing SDN Smackdown issue, there's no shortage of proprietary overlay alternatives, including products from Midokura, Plexxi, and Plumgrid. All of these include some level of support for the OpenStack Neutron network plug-in, meaning virtual network resources on OpenStack can be managed and controlled within a broader overlay network design.

>> Layer 7 network APIs and physical and virtual network resource management and automation. Network controllers and northbound APIs are seeing especially active development, debate -- and uncertainty. Network equipment vendors realize that the standards, APIs, and protocols used to program and control the network have implications for every device on the network.

The most important open source effort in this realm is OpenDaylight, a project broadly supported by industry heavyweights that made its first public code release this spring. In fact, the OpenDaylight Hydrogen project won the 2014 Best of Interop Grand Award because it's not only a strong product, it shows what industry-wide collaboration can deliver. Hydrogen is a modular SDN controller that can support any number of southbound interfaces to control both hardware and software networking products as well as northbound interfaces accessible to a variety of SDN applications.

Another open effort to address virtual network application interoperability is the recently announced Open Network Function Virtualization (OP-NFV) project under the Linux Foundation. The goal is to establish an open source reference platform to advance the evolution of NFV and ensure performance and interoperability among multiple open source components. The software's initial focus will be open APIs for NFV infrastructure management and automation that bridge the gap between virtual infrastructure platforms, such as vCenter with NSX or OpenStack, and higher-level network services, like mobile or tunneling gateways, firewalls, content filters, or monitoring services.

OpenDaylight's most significant commercial competitors are Cisco's Application Centric Infrastructure (ACI), along with the new Cisco APIC controller, so far only available as a hardware appliance, and VMware NSX, an expensive add-on to vCloud Suite. OpenDaylight also has open source competition in the form of OpenContrail, a product Juniper acquired and later released as a public project, and the Open Networking Foundation (ONF), custodians of the OpenFlow standard. ONF has working groups developing an architectural framework, northbound interfaces, configuration and management specifications, and interoperability guidelines that could ultimately be incorporated into an open source OpenFlow controller like Floodlight. That could result in a viable alternative to OpenDaylight or APIC.

Bottom line: SDN adopters are likely to favor open source projects, if developers can keep complexity under control.

Big data platforms

Open source software, primarily via the Apache Hadoop project, is arguably the reason big data software has achieved widespread use. Although the technology for large, distributed databases, parallelized data processing and search, and distributed resource management and scheduling long predate it, Hadoop, the open source framework for distributed processing of large data sets across clusters of computers, is the software that launched not just a thousand but perhaps millions of implementations and spawned an ecosystem of ancillary big data software.

Although the source code is freely downloadable, most enterprises use either a commercial Hadoop implementation, popular ones being Hortonworks, IBM InfoSphere, Intel, MapR, Pivotal (EMC) Greenplum, and Sqrrl, or a Hadoop service, like AWS Elastic MapReduce, Cloudera, or Google Cloud Platform.

Of course, the big advantage of a common data platform is that applications should be portable among implementations. Indeed, Spotify made headlines last fall when it migrated its Hadoop infrastructure from Cloudera to Hortonworks.

Even Oracle has been forced to embrace Hadoop. It offers an integrated Hadoop appliance and data integration software to transfer data between Hadoop and Oracle's SQL database, along with its own NoSQL alternative.
Another popular big data platform is SAP's in-memory HANA. Unlike Hadoop, HANA is a relational database with full ACID compliance; Hadoop HBase has only limited ACID properties. HANA provides very high performance due to its in-memory design, yet still scales to multiterabyte data sets and has become the model for other in-memory database systems. We expect to see more competition from open source alternatives like Hazelcast and VoltDB.

Bottom Line: Remember, you don't need Hadoop or its alternatives just because your data has outgrown Excel. Unless the data set measures in terabytes or the system must rapidly ingest large data streams from many sources, big data platforms are overkill. However, when the time comes that you do need such a platform, open source projects have brought them within financial reach of most companies.

For enterprise IT, open source purity is neither possible nor desirable. Instead, demand interoperable, flexible products resistant to lock-in. Support vendors that back open source projects, use standard APIs and data formats, publish their own APIs and data formats, and build a variety of connectors. Evaluate any potential code in 12 areas: features, performance, reliability, scalability, usability, interoperability, adaptability and programmability, security, vendor and community support, software ecosystem, technology road map, and price. And trust that when proprietary vendors and open source projects coexist peacefully, everyone wins.

Get the new issue of
Network Computing.