I see lots of wildly varying ways of defining software defined networking (see what I did there?) that don’t seem to jive. The press especially seem to have zero clue exactly what it is, and if we’re honest with ourselves, most IT professionals don’t either.
Rather than lament on this fact further, I reached out to a good friend of mine that I’m sure you have met. Infamous for his completely unwanted advice popping up into your screen, the hero of Microsoft Office, Clippy, accepted my meeting request and agreed to be quoted “on the record” about how the phrase software defined networking should actually be used going forward.
This is an exclusive, behind-the-scenes access into the star studded world of a paperclip with a dream.
It’s Not Software Switches
My first question to Clippy was around software switches, such as the vSphere virtual switch, the Open Virtual Switch (Open vSwitch), a Vyatta vRouter, or the Cisco Nexus 1000v. Are these, as some media outlets would have you believe, software defined networking? They run on software, right, so they must be SDN!
After a discussion with Clippy, we agreed that these technologies are NOT software defined networking in of themselves. Just taking a switch and virtualizing it is really more of a way to enable more free form control of the network and take further advantage of virtualization. Virtual switches also solve a number of issues around how traffic flows in a virtual environment – this is sometimes referred to as dark traffic because layer 2 adjacent workloads inside of a virtual host typically do not have to ever touch a physical switch further north of the hypervisor.
However, it is important to point out that many of the products I mentioned above do enable software defined networking because they can be programmatically defined by a non-human via APIs and other orchestration (vCNS / vShield, OpenFlow, Puppet, Chef, etc.). No network engineer has to sit down and actually write out CLI commands to configure the switch. The software, or workloads, that ride on top of the virtual switches can actually define the network that is needed for them to be functional. The software switches are software definable.
It’s Not Having an API
OK, so if just having your switch in software isn’t SDN, how about adding an API to allow people to program your virtual switch using code. Ah ha! This MUST be SDN, right?
Clippy makes it quite clear that just having an API does NOT make any product a software defined network. Again, this is simply opening up the virtual or physical device to being software definable and is a key component to creating a software defined network. It’s a bit like giving the device a pair of ears and hands to do work, but leaving the brain part with the higher level workloads. The device takes orders via the API (using those ears and hands) to program itself as part of a larger fabric. It can also respond to state requests so that entities higher up in the stack can query the state of things.
We’ve both seen too many examples of where a product is given an API and then magically announces that it is a software defined widget. Software definable, sure (and even human definable). But the API is (typically) not giving the orders. That, my friends, is just marketing mumbo jumbo!
It’s About Workload and Application Control
The point of software defined networking, according to Clippy, is shifting control of the network up the stack. All of the network bits, be it firewall rules, security zones, VLANs, traffic shaping, filtering, queuing, and monitoring should all be wrapped up in a nice little policy package and applied to the workload in software. The policies are defined by an architect and usually define a tier of service, such as “Production Workloads”, or even more granular to different cloud tenants like “Bob’s Production Workloads”.
When a workload is deployed into an IaaS or Cloud, the policy then communicates with the networking plumbing to ensure that the requirements are configured and enforced. This eliminates the operational hassle and business risk of having a person define all those network bits each and every time. It also gives the architects and engineers more time to focus on ways to accelerate and improve the network, instead of just completing tickets in the queue and keeping the lights on.
As Clippy says above, there are a lot of moving parts in most networks, and they tend to get exponentially complex as you scale out. The best designs are nearly always the ones that keep things simple. Simple is fast, agile, and less risk prone, while complex is slower, clunkier, and more risk prone. Letting clearly defined policies at high levels in the workload stack define the network via software create simple and scalable networks.
Agree or disagree? I’ll leave you with a fun chat I had with Omar Sultan at Cisco Live 2013 where we discuss turning unicorns into plow horses (his words) with SDN. 🙂
