Perhaps I’m in the minority that is still frustrated by this, but as a marketing person who is tasked with explaining technology and solutions to customers and prospects, I feel hamstrung by a lack of a widely agreed upon definition of what is and is not “SDN” still. This usually comes up in discussions about our new Application Centric Infrastructure (ACI), and how it compares to traditional SDN concepts, as well as alternative approaches, such as overlay networks advocated by VMware.
The topic came up again this week with a NetworkWorld article in which the head of VMware’s network virtualization business is now saying, “SDN will never happen” (our rebuttal). Well, what is happening, if it’s not SDN? Or just because the technology has evolved, do we need to create a new term just because some early assumptions the industry made have changed? As we start out a new year, I thought it a good time to try and reframe the definition, and look at how the trends in SDN may be shaping up to extend the concept into new areas.
Why do customers need SDN?
By early 2012, there was so much hype and expectations around Software Defined Networking, focused on the ability to “program” the network, that real customer use cases and the killer SDN app was lost in the conversation. But what slowly emerged, that is driving all the investment, pilots and product designs is a much better way to manage the data center and cloud network, and to automate IT tasks so that the infrastructure could respond dynamically to rapidly changing business conditions and requirements. The “intelligence” to make all that happen is moving from the network devices and device management consoles, to centralized policy-management platforms, orchestration tools and cloud-managers.
What’s caused the biggest evolution in SDN is the realization that very few organizations really have the desire, skills and incentives to write a new class of applications to a published API to program the network. These users are outlying use cases compared to the vast majority of organizations just looking to automate IT tasks, accelerate application deployment, make their cloud networks more flexible, and better align their IT infrastructure with business requirements. The focus has shifted from SDN being an open API/controller platform, to a platform capable of hosting a myriad of orchestration and IT workflow automation solutions that drive customers to their end goal. To that end, ACI is meeting all those objectives, and in more advanced and innovative ways than earlier SDN approaches.
A historical look back and what SDN was supposed to be
Initially, SDN was generally defined as moving the control plane of a network device to a generic software platform (a controller) and being able to programmatically extend the control plane to optimize or modify network behavior. SDN was characterized by the logical separation of the control and data planes, with programmatic control of the former. The early platforms that consisted of an OpenFlow controller and OpenFlow enabled switches certainly defined the known universe of SDN solutions. And OpenFlow was probably unfairly linked to being a requirement for SDN back then.
When Cisco announced its Open Network Environment (Cisco ONE) approach in 2012, it significantly broadened many of these concepts to focus more on aspects of open networking, and to address various deployment models, taking a use-case led approach. It included OpenFlow, but also expanded the conversation into open source (e.g., OpenStack), open APIs (REST and onePK), as well as options to incorporate a software controller. These principles continue to be extended.
Comparing ACI to the traditional view of SDN
Similarly, when we introduced ACI less than 3 months ago, there was a great deal of confusion whether ACI was SDN or not. There had been long anticipation that Insieme was working on an SDN solution, so ACI must be a form of SDN. And, yet, according to the accepted notion of SDN at the time, Cisco was quick to point out ACI was something quite different. Cisco pointed out that we had “bypassed the first generation of SDN”, implying that ACI was an evolutionary leap over SDN. But if it was not SDN, what was it?
While ACI includes an SDN network controller component (the Application Policy Infrastructure Controller, or APIC), the internal programming model was very different, in that it was focused around application provisioning, including all the networking, security and application services infrastructure. Another key differentiator for ACI was that it optimized the network fabric for both overlays and physical workloads/connections. ACI also promised to extend its application policy model beyond the network and services, to servers and storage, to encompass the entire data center and cloud infrastructure. Clearly, this was well beyond just software-defined networking.
ACI skeptics even went so far to call it HDN (Hardware Defined Networking) since implementation of the ACI fabric was tied to the newly launched Nexus 9000 Series switches, hinting that for something to be “SDN” it had to be open and multi-platform. The truth is that the ACI policy model and APIC controller are software-based, but Cisco has followed the trend to optimize key fabric tasks in hardware, primarily for scale and performance. We can see the same thing today with what were once purely software overlays (VXLAN specifically) that were encapsulated in soft-switches. Now we see, for performance and scale, VXLAN encap/decap and VLAN mapping are migrating to physical switches and gateways with supported features in hardware (such as the Broadcom Trident II chip set). So, yes, there is hardware support in Cisco devices to optimize the ACI fabric, but it is inherently a software policy model, with a software controller, and we have a large partner ecosystem integrating their products into the ACI fabric without specialized hardware. It truly is a software-based policy model, comparable to other SDN approaches.
Increasingly, the industry is now referring to ACI as a “flavor” of SDN. Clearly, the original notion of programmatically controlling your network exists in ACI, even if much has been added to the policy capability, extending it well beyond the network, with hardware optimization.
Recently, Ethan Banks wrote an article for Network World comparing Cisco ACI to the VMware NSX virtual overlay approach, ostensibly under the banner of “an SDN showdown”. And Cisco’s own Mike Cohen wrote an excellent blog on what to watch for in 2014 for SDN. Many of Mike’s observations related to trends we are seeing with ACI affecting the SDN landscape, such as accelerating application deployments being the killer app for SDN in 2014, and that Layer 4-7 service chaining (for security and app controllers, e.g.) will be a key requirement for SDN solutions. All great insights, and key factors that will make ACI successful.
The bottom line is that the industry appears to be embracing broader and more complete definitions of SDN as the technology evolves and matures. While it may not have been explicitly stated by Cisco before, I think it can only clarify conversations that ACI is indeed a class of SDN solutions, according to the newly expanded definitions. There is certainly no one way to program a computer, and we are seeing there are multiple models of programming a network (and the infrastructure as a whole). We embrace the distinction.
As such, we have begun to include the ACI APIC controller in our own expanded definition of the Cisco ONE platform, along with our XNC controller (our commercial version of the Open Daylight controller), and other enterprise controller solutions. And this only makes sense. But if it’s been lost on anybody, the important evolution that we are seeing in the SDN world is that SDN platforms and solutions are more and more becoming the foundation for more advanced orchestration and automation solutions, such as OpenStack, UCS Director, and others.
Perhaps organizations writing programs to controllers and open API’s to control and optimize network behavior was really a specialized use case. The real power of SDN is going to be as the foundation for richer and richer automation and workflow solutions that don’t require much programming, but ultimately do what users really want: accelerate all of their IT tasks, and allow their IT infrastructure to instantaneously respond to changing business requirements. Like ACI does.
You may still think of ACI as SDN or something else altogether, but, like Shakespeare said, “A rose by any other name would smell as sweet…”
This in no way clarifies anything. In fact, its a distraction to that conversation. Dont kid yourself, ACI is a slide deck..