Two of the hottest trends in networking today are SDN and network disaggregation. This is great for many reasons. It’s also confusing. The marketing hype makes it hard to understand either topic. SDN has become so vague that if you ask 10 experts what it means, you are likely to get 12 different answers. Network disaggregation seems straightforward enough, until it gets confused with SDN. We need to take a step back. Let’s start with a simple explanation of each of these trends and then see how they interact.
Software Defined Networking (SDN)
I try not so use the term “SDN.” As Ethan recently pointed out, its been so badly abused that it has, essentially, lost all meaning. The flip side is that the term isn’t going anywhere. Companies are selling SDN and executives are asking for SDN. Just like “cloud,” we seem to be stuck with “SDN.” The best we can do is work to agree on a common, if general, definition – and be more specific whenever possible.
For now, we’re left to define the term every time we use it. At its core, I believe that SDN has two components; network automation, and network analytics. Automation encompasses concepts such as logically centralized management, network programmability, and network abstraction. Analytics provides the information you need to make informed decisions when planing, building, and operating your network. Analytics also provide the feedback needed for advanced automation (i.e. autonomous networks). Whether you use OpenFlow or overlays, whether you write your own Ansible playbooks or leverage complex orchestration systems; the fundamentals of SDN are always the same. Putting information into the network, and getting information out of the network.
Using this definition, I don’t see SDN as an option as much as an inevitable progression of network management. Networks are becoming more and more vital to our society while the ratio of devices to engineer continues to climb. We must find ways to simplify network operations and increase network efficiency. Today, those solutions fall under the umbrella of SDN.
Here’s another imperfect term. Taken literally, “network disaggregation” means to separate the network into its component parts. Wouldn’t that just mean looking at individual routers, switches, and firewalls? More specifically, we probably should say ‘network device disaggregation’ or ‘hardware and software disaggregation in network devices.’ Too bad those phrases are so unwieldy.
What we’re talking about here is the ability to source switching hardware and network operating systems separately. This is like buying a server from almost any manufacturer and then loading an OS of your choice. This is where I’m supposed to say, “thank the heavens that networking is finally catching up to systems.” And it IS great that this is an option now. The proliferation of “whitebox” and “britebox” switching platforms, combined with the explosion of available network operating systems (NOS’), are together putting pricing and innovation pressure on the legacy “aggregated” networking vendors. Don’t forget however why so many people love their Apple products; sometimes it still makes sense to engineer hardware and software together.
Combining SDN and Disaggregation
One of my pet peeves right now is when people confuse SDN and network disaggregation. You’ve probably heard it too. Someone brings up SDN, which triggers someone to launch into an argument for or against whitebox switching. While commodity switching hardware was one of the initial promises of SDN, it has never been a hard requirement. Deploying disaggregated network devices and deploying SDN are not the same thing. There is an obvious relationship between the two though. Let’s think of SDN in terms of a logically centralized management plane. That management plane must interact with network devices to be useful.
Looking at that interaction between software management and network devices provides a quadrant graph that may be useful when charting your course into an SDN future:
This graph uses two vectors. On the left we measure network devices from proprietary and aggregated to open and disaggregated. On the bottom we measure the type of SDN deployment from purchased and pre-packaged to developed in house (roll your own). The resulting quadrants provide a simplified set of targets to plan against. This isn’t the Gartner magic quadrant, there is no value judgement here, so let’s look at some of the pros and cons of each.
Open Devices, NetDevOps Management
In quadrant I we find the most flexible, but most developer focused, solution area. Here we find open networking devices with open protocols and tools. To get here you buy commodity hardware, load a NOS, and develop your own SDN solution to provide exactly the control and visibility you want. It’s likely that you’ll spend the least on software and equipment, but you’ll need to have talented developers on staff (or on call) to build and grow the solution. This is a crowded realm full of folks like Edge-Core, Dell, Juniper, Celestica, Mellanox, HP, Cumulus, Pica8, Plurabis, IP Infusion, Python, Ruby, Perl, NAPALM, Ansible, Puppet, and Salt – just to name a few.
- No vendor lock in
- Extreme flexibility
- Lowest CAPEX
- Requires specific talents
- Least support if it breaks
- Lots of decisions to be made
If you’ve got a talented NetDevOps team, love open source, don’t mind a little uncertainty, and want to be able to change almost anything at pretty much any time; this is probably the quadrant you want to shoot for.
Open Devices, Packaged Management
Quadrant II keeps the open networking devices (network disaggregation) but introduces a packaged SDN solution. To get here you buy commodity hardware, likely pre-loaded with a NOS, and then buy an SDN solution that meets your requirements and works with your chosen devices. You’re still saving money on equipment, but likely spending more for software in the form of a controller or orchestrator of some kind; maybe even a full-blown Lifecycle Service Orchestration (LSO) package. Big Switch (see comment, below) or Apstra may make a great fit here.
- Low cost commodity hardware
- Easier to deploy
- Higher software costs
- Potentially locked in to SDN vendor
If you want the flexibility and cost savings of open networking devices without the hassle of developing your own SDN solution; this is your best bet.
Proprietary Devices, Packaged Management
The lower left is quadrant III and here we find the least flexible but best supported option. This quadrant combines proprietary aggregated network devices with a packaged SDN product. To get here you most likely go through a single RFx process, select a single vendor, and pay them to build a complete network system to your specifications. You’re spending the most money, but getting the most cohesive solution and support. This is the land of Cisco and Juniper; although you may be able choose different vendors for different components/layers.
- “One throat to choke”
- Least new skills to learn
- Fewest decisions to be made
- Vendor lock in
- Least flexibility
- Highest CAPEX
If price and flexibility are secondary to having it “just work” right now with full support tomorrow, you’ll likely want to aim here.
Proprietary Devices, NetDevOps Management
Quadrant IV is a hybrid of proprietary network devices and open network management. To get here you buy your favorite vendor’s aggregated devices and then roll your own SDN solution to provide exactly the control and visibility you want. You’re spending money on hardware but building in flexibility, so you’ll need developers. In this area folks like Arista, Cisco, and Juniper are joined by Python, Ruby, Perl, NAPALM, Ansible, Puppet, Salt, and others.
- Increased flexibility
- Decreased vendor lock in
- High cost proprietary hardware
- Requires specific talents
If you’re ready to unleash your NetDevOps team to build a flexible SDN solution, but want the comfort of a more traditional and fully featured hardware underlay; set your sights on this quadrant.
The Bigger Picture
As it says in the title, this is a simplified approach. I’ve smoothed over a lot of nuance, and left out a lot of details and corner cases. Many solutions won’t fall neatly into one of the four boxes above. This is certainly not an exhaustive treatise on SDN and network disaggregation. Hopefully it is a helpful taxonomy of one of the key decision points on your journey to the network you want.
Was this helpful? Did I get something wrong? Please let me know in the comments below!