Packet Pushers Interactive
Published: 20 May 2014
Software-defined environment chatter is flooding the network market, making it hard to find the real technologies and value.
Software-defined networking (SDN) is one of those technology buzzwords that just won't go away. SDN continues to grab the lion's share of networking headlines, and vendors are adopting it as some sort of fashion statement, affixing the moniker to any part of their product line that could be somehow connected to software, automation, programmability or SDN's trendy neighbor, DevOps.
For IT professionals, the result of all this hype is confusion. Yet SDN has real value. For IT teams right now, it's not about implementing SDN technologies, it's about getting your IT environment ready for SDN.
Done right, SDN lowers costs and provides far greater flexibility and efficiency than traditional networking. A software-defined environment lets applications communicate their respective needs to the network directly, paving the way for automated network provisioning, speedy service delivery and powerful new ways of managing traffic. But how far are we from that vision? What parts of SDN are real? Is SDN settling down into something predictable, and how is 'software-defined' really impacting organizations that rely on networks to drive their business forward? Let's extract hard data from the marketing morass.
Today, networks are provisioned largely by hand. Software-defined networks can be programmatically configured by a central controller that manages all network devices holistically. Engineers configure individual routers, switches and firewalls to perform in accordance with business needs. Although much of IT has automated their core processes -- think server virtualization -- networking hasn't followed suit. The reason is that network designs and equipment vary widely by organization and business practice. SDN's aim is to chase away those challenges by placing a uniform layer of abstraction between IT applications and the underlying network infrastructure.
If 2011 and 2012 were the years of big SDN ideas, 2013 and 2014 have been the years of big SDN product announcements. Still, vendors have struggled to decide just what sort of a product to bring to market, since software-defined environments are potentially disruptive for both vendors and their customers. Incumbent vendors have built products that both align with their existing market positioning and offer an easy transitional path into SDN.
A tale of two SDN vendors
Cisco's Application Centric Infrastructure (ACI) debuted in late 2013 with much fanfare. Cisco's ACI vision is broad, encompassing the entirety of the data center environment: Software and hardware are orchestrated together to deliver applications driven by policy. This notion of delivering IT services came from Cisco's spin-in company, Insieme Networks, whose hardware switches and software controller are now known now as the Cisco Nexus 9000 and Application Policy Infrastructure Controller (APIC). The Nexus 9000 and APIC are based on the notion that a fully software-defined network cannot ignore integration of hardware into the application delivery scheme. On the ACI platform, Cisco provides multi-tenancy, service chaining, security, Quality of Service and other key network functions across an end-to-end Nexus 9000 infrastructure managed through APIC.
Cisco's approach with ACI is technically sound, but it also makes sense from a business perspective. After all, Cisco is in the business of selling hardware, specifically Ethernet switching gear. ACI can be seen as a rebuke to some in the SDN world who believe that hardware is a secondary concern: Ethernet switches simply need to forward, and let the real SDN magic happen at the edge of the network in hypervisor-based virtual switches.
VMware is a proponent of the idea that the software part of SDN is the critical element, and that the hardware itself can be deemphasized. Since it announced its NSX platform in August 2013, VMware has taken the stance that the best parts of software-defined networking happen in the hypervisor. The hypervisor-agnostic NSX controller works with a variety of virtual switches to deliver multi-tenancy, service chaining, security, etc., by managing the traffic both inside of a hypervisor and between hypervisors. Thus, unlike in a Cisco ACI environment, NSX does not manage traffic between hypervisors as it crosses the physical switching infrastructure.
VMware's NSX approach has a clear advantage over ACI: NSX is not hardware dependent. While Cisco's APIC currently relies on the Nexus 9000 hardware, NSX can run over any data center environment, as long as you have an IP network.
While Cisco ACI and VMware NSX are both software-defined technologies, IT architects should keep in mind that they do not do all of the same things. Cisco's vision of SDN is broad; it sees a world where policy control of all data center network elements will eventually fit under the ACI umbrella. NSX, while more mature than ACI, is more narrowly scoped. VMware states that it does not plan to get into the business of managing hardware. Not all customers will be interested in having NSX managing their hardware; many have already found that NSX immediately eases the administration burden of complex multi-tenant networks.
Cisco has responded to criticism of Nexus 9000's hardware dependence by opening the APIC controller to the industry via Opflex, a way for vendors to integrate their hardware with APIC. Should vendors choose to take advantage of Opflex, ACI's ability to manage the data center will continue to grow. Opflex means that NSX and ACI could be complementary technologies in certain network architectures.
While data centers scrutinized ACI and NSX in 2013, numerous established networking names as well as startups joined forces as members of the open source project OpenDaylight (ODL), managed by the Linux Foundation. ODL is a consortium of networking vendors -- notably Cisco and VMware -- that pay to be a part of the project, and also contribute code and developers. Its mission is to develop an SDN controller that, like ACI and NSX, takes instructions from applications above it and programs the network underneath it. ODL promises to become a baseline of SDN functionality that the entire networking industry can reference, bringing standardization and predictability.
ODL released its 1.0 product code-named Hydrogen in February. Hydrogen represents enormous potential for the networking industry, showing a way that all vendors can work together to bring a unified software-defined vision to market.
Cisco, VMware and OpenDaylight are by no means the only players in the SDN market. For instance, Hewlett-Packard has an SDN app store that provides IT organizations an easy way to consume networking applications that integrate with the HP SDN-capable network. Then there's NEC, whose ProgrammableFlow network architecture is one of the most mature SDN offerings on the market, composed of a controller, hardware switches and rich set of networking applications.
There's also a thriving SDN startup scene, with novel products that disrupt the status quo:
- Big Switch: A controller and switch pairing from a long-time technology leader in the SDN space. Big Switch has a number of interesting partners in the industry, enabling customers to build feature-rich networks that are controlled centrally.
- Cumulus: A Linux operating system that runs on several Ethernet switches, including some from Dell. Cumulus caters to those who would like to manage their switches like they manage their servers.
- Pica8: A software company selling hardware switches that can be managed in a variety of SDN-friendly ways. Pica8 sells at very cost-effective price points.
- Plexxi: A controller and switch pairing. Plexxi hardware uses an optical backbone between switches, analyzes traffic flowing throughout the network and then prioritizes traffic between switches across their optical backbone using a strategy known as affinities. Financial services companies have reportedly found many uses for Plexxi affinities.
- Pluribus: A server switch. The recently unveiled Pluribus product is a top-of-rack switch that is actually a server with a very high-speed control bus to the switching silicon. Pluribus switches present themselves as a unified fabric to applications that leverage the high speed bus to perform high speed analytics and other rich networking functions.
The big picture
IT shops considering adoption of software-defined environments should keep several things in mind. The SDN marketplace is immature. There is no one way that SDN looks. Much of the SDN technology on the market today represents specific solutions to solve specific problems. Not every organization will have a problem set that matches well with every SDN solution that exists. The safe bet is to invest in new technology that is SDN-capable. An organization might not be ready to move to SDN today, but their hardware and software should be ready when they are.
A key consideration when evaluating a new SDN-related purchase is whether it is possible to programmatically configure a given piece of hardware. The hardware should be able to be configured in some way other than a GUI or CLI interface requiring direct interaction with a human being. Rather, a script, controller or other sort of code should be able to program the device.
Organizations should also consider a given vendor's partnerships and alliances. Will the product integrate with the Cisco APIC controller? What about VMware NSX? What about OpenDaylight? If the answer is that the vendor will only work with their respective controllers, then that could be a red flag. While it is unclear what SDN model the industry might ultimately adopt, it is clear that both vendors and customers want interoperability.
SDN adoption will impact operations in much the same way that server virtualization did. The shift from physical hosts to virtual hosts impacted spending, process and employee skills. SDN will shift spending toward controllers and software and away from hardware. Processes around the provisioning of network switches, load balancers and firewalls will change. Network engineers will need to learn additional skills to understand and troubleshoot network configurations in an SDN world. All of this implies disruption, but if it is anticipated, that disruption that can be minimized.
Organizations may need to examine their respective IT organizational plans, as SDN is certainly a silo buster. It no longer makes sense to organize IT teams vertically, along application, storage, virtualization and networking lines. Organizations are better served by realigning IT teams in ways that allow open communication between technology specialists.
As organizations begin to adopt software-defined products in earnest over the next two to three years, those that anticipate and prepare for the change will gain the greatest competitive advantage.
About the author
Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. He co-hosts the Packet Pushers Podcast. Contact him at @ecbanks and visit ethancbanks.com.