Will Software Defined Networking Actually Happen?

As a writer for the IT media, conference speaker, and co-host of the Packet Pushers podcast, I cover emerging networking technologies often. The new tech that comes across my screen ranges in value from “I can’t believe that got funded,” to “Why has no one thought of this before?” and everything in between. As a big idea, software defined networking (SDN) seems to generate about that same range of responses from network engineers. Some networkers think that SDN is an extraordinary technology that’s going to change the world of IT. Others see SDN as yet another in a long string of quirky networking ideas that never gained acceptance. In fact, as I’ve read responses to my SDN-related content over the last few years, I believe that more folks are in that latter camp. SDN is a fad. SDN is a buzzword. SDN will go nowhere useful. SDN will eventually fail to have a universal impact.

I understand the cynicism. After all, for a long time, networking had lapsed in an innovation coma, with nothing especially exciting coming along to really shake things up. Yes, Ethernet’s gotten faster. And that BYOD thing got everyone excited a couple of years ago. But for the most part, we design, build, and operate networks the same way today that we did fifteen or more years ago. The core underlying protocols have grown up or had new knobs and levers added, but generally speaking, if a networker of the past fell out of a time warp and into a design project today, it wouldn’t take them too terribly long to catch up.

That said, software defined networking is different. Although networking is hardly a game, SDN is the proverbial game changer. SDN is the new, emerging, extraordinary technology that is poised to fundamentally shift the way networking is done. So, if you’re a networker or industry observer asking, “Will SDN actually happen?” I believe strongly that the answer is, “Yes.” SDN not only will happen, but at the risk of being accused of hyperbole, I believe that SDN must happen. I’ve now put myself in the unenviable position of having to defend that statement, but I think that I can do it by making three simple points.

1. Traditional networking is inflexible. One of the great challenges networking faces is that of virtualization. Compute infrastructures are extremely flexible, allowing virtual machines to move to unpredictable points within a data center, or even between data centers. In addition, virtualized infrastructures lend themselves very well to automation, meaning that systems engineers or the automated systems they manage can spin up new compute instances very quickly — even on demand. The best networking has to offer that can match that level of capability growth is VLANs and Data Center Interconnect (DCI) protocols. As long as the network allows the compute infrastructure to put any virtual machine anywhere it might need to go with little or no cross-team communication required, the IT teams stays happy. Happy enough, anyway.

The “put all the VLANs everywhere” approach works well enough so long as nothing interesting is expected of the network. By “interesting,” I mean that nothing is being asked of the network other than delivery of frames and packets between endpoints.  As soon as more is required, the network’s inflexibility becomes a roadblock to moving a compute infrastructure forward. As a networker, consider these examples, then decide in your own mind if these tasks are, at present, straightforward, challenging, or impossible.

• Dynamic QoS that guarantees call quality between endpoints, no matter what path that call takes.
• Load balancing across wide-area links in reaction to current link quality and utilization.
• Creating network containers that isolate networks one from another while sharing the same physical infrastructure.
• Identifying malicious traffic flows and steering them towards a mitigation device.

Using traditional networking paradigms, none of these tasks are straightforward. The average networker reading this can come up with various solutions with traditional technologies to these challenges, but none of the potential answers match the sort of flexibility that compute has come to enjoy.

2. SDN enables flexibility. A key aspect of software defined networking is that it provides an interface to the network. Interfaces most networkers are familiar with include the CLI, various GUIs, and SNMP. While SDN can leverage those sorts of interfaces when required, it’s new Application Programmatic Interfaces (APIs) that are the most interesting for SDN. APIs provide a way for developers writing software to interact with the network. To get information from the network about its state. To program forwarding tables. To abstract the differences in hardware that exist among platforms, making it easier to achieve the same goals in the same way, despite a heterogenous environment.

In summary, APIs, such as those found in Cisco’s onePK, allow networks to be programmed. And thus, we get to the guts of what a “software defined” network is all about. A software program can interface with the network using a series of multi-layered APIs, and make the network do something — achieve some sort of specific IT goal, presumably in harmony with the compute infrastructure. And if you believe that the network working together in harmony with the rest of the IT infrastructure is a laughable idea or maybe even dangerous, you’re missing where IT is going. The days of IT silos are ending, ITIL notwithstanding. For IT to be done right, all components of IT must work together to realize a business outcome. The network has been a weak link for a long time due to the lengthy, error-prone provisioning process. SDN is shoring up this weak link.

If I’m not convincing yet, begin reading up on Cisco Application Centric Infrastructure (ACI). ACI is in its early days, but stands to be the single most important initiative in Cisco’s vast landscape of products. Why? Because in the long-term, ACI could very well be the focal point for many if not all of Cisco’s rich catalog of IT offerings. ACI can integrate physical network, telephony, compute, and security products into one centrally managed IT engine that allows businesses to treat their IT infrastructure as a single entity that works to meet a specific business goal. I believe that Cisco engineers who understand how ACI works, can fix it when it doesn’t, and can interact with it efficiently and effectively will be ahead of those who cannot. In the Cisco world, I don’t see ACI as a corner-case tool useful only to big organizations, massive data centers, or service providers. Instead, I see ACI as a foundational technology that, over time, many network and compute applications will interact with tightly. What’s more, ACI is attracting a large ecosystem of third party vendors who are making their products work with ACI.

3. A breed of new applications is the result. What sorts of applications does SDN enable? The biggest class of SDN functionality that Cisco ACI enables is in the realm of automation. Cisco has already published solution briefs with a number of different vendors, explaining how ACI integrates those products with the network infrastructure, all via the Cisco Application Policy Infrastructure Controller (APIC). Published solutions include Cisco ACI integration with the following vendors.

• Microsoft. Cisco ACI integrates with Microsoft Hyper-V environments via the Microsoft System Center Virtual Machine Manager, allowing APIC policy to be applied to Hyper-V workloads, including service chaining (passing VM traffic through firewalls, application delivery controllers, etc.).
• VMware. Cisco ACI integrates with vCenter and vSphere workloads in a similar way to Microsoft Hyper-V and SCVMM.
• Citrix. Cisco ACI integrates with Citrix NetScalar devices. APIC is used to configure the NetScalar devices automatically, in accordance with network policy.
• Others. Integrations with other vendors & open source projects exist, including F5, VCE, NetApp, Puppet, OpenStack, Red Hat, and Splunk. And those are just the published solution briefs. Many additional vendors are part of the ACI ecosystem including A10, CA, EMC, Embrane, IBM, NetQoS, Nutanix, Panduit, and Symantec.

I believe that automation is just the beginning. Already, we’re seeing other interesting SDN-centric applications come to the market, including SDN WAN vendor & Cisco partner Glue Networks. Glue’s Gluware Orchestration Engine integrates with Cisco gear via APIC and onePK. Gluware makes possible novel WAN traffic forwarding and policy management via an easy-to-use interface with an astonishing amount of power considering the behind-the-scenes complexity.

My point in this blog really is this: software defined networking isn’t just a fad. SDN is not going to fade away after no one buys it. Rather, SDN is addressing a specific networking industry need. Not only that, SDN as a technology space is a hotbed of innovation and original thinking. As I hope I’ve demonstrated, Cisco is as serious as any vendor in this space, offering in ACI an SDN solution that is massively broad in scope and aligned with vendors across the industry. While ACI isn’t the only SDN solution out there, it’s clearly an important one the industry is taking an active, participatory note of.

To be fair, “Will SDN actually happen?” isn’t even the right question at this point in time. In fact, SDN is already happening. Right now. Today. The right question is, “What will you do to be a part of SDN?” Answer that, and move your career ahead.