10 Misconceptions (and Lies) about SDN

(1)  SDN is no longer just for the Hyper-scale Web Companies or Academics – SDN started off as an academic exercise, and the earliest SDN implementations were in academic lab environments followed by the hyper-scale web guys where massive scale required a new approach to deal with 10,000+ network changes a day.  However, SDN implementations are now creeping into the mainstream, slowly but surely.  In fact, so much so that we’ve just published this SDN research aimed at mainstream enterprise.

(2) OpenFlow does not equal SDN – This is an older mentality but many folks still use OpenFlow and SDN interchangeably.  Openflow is a piece of the SDN story, as the first major southbound SDN protocol.  But Openflow alone is not SDN; SDN is much bigger.

(3) White-box switching is not the same SDN – These two terms are usually associated together, but they are not the same.  You can do white-box without SDN (just ask Dell and Cumulus), and you can do white-box within an SDN.  So while related, they are disaggregated (pun intended).

(4) Programmable Fabrics are nice, but they’re not SDN – Several vendors offer programmable Ethernet fabrics (sometimes with Open APIs) that are commonly referred to as SDN.  These are often very nice products that solve real customer challenges, but they are not SDN. 

(5) Programmatic control does not mean developers “own” the network – Network folks tend to get a little twitchy when they hear that SDN allows “programmatic access to the network”.  The typical response is “The last thing I want is developers controlling the network”.  This is not what SDN provides.  Instead, App Administrators can write APIs that communicate with the network controller via pre-defined templates or blueprints.  These functions on the controller are typically setup by a Networking person.  This isn’t the wild-west (sorry, application guys).

(6) VMware and Cisco are not the only SDN players – There is a lot of talk about VMware NSX versus Cisco ACI and their battle for data center networking influence.  However, there are a number of other players in the SDN space; including mainstream trusted IT vendors as well as startups (Juniper, HP, Nuage, PlumGRID, Midokura just to name a few).

(7) SDN is not a “network upgrade“– SDN is not something you slather across the network over a long weekend like a switch upgrade – it should be deployed opportunistically along with specific use-cases or drivers/pain-points.  Think of the way we deployed load-balancers in the 90s.  It wasn’t all the apps on day 1; it was the ones with specific requirements (i.e., scale/resiliency).

(8) Automation is not SDN – one of the most common benefits cited for SDN is networking agility – specifically the ability to delivery networking services to the business faster.  This can be delivered via orchestration and automation tools as well.  Hence, there is often confusion around orchestration and automation equating to SDN.  Like programmable Ethernet fabrics, automation can solve customer problems, but are not SDN.

(9) Any vendor who tells you they’ve been doing since before it was called SDN is probably lying – These are vendors who are now claiming to have been doing “SDN before it was cool“.  Some are telling the truth, but most are really spinning things. 

(10) SDN is not just about the network team – By definition, SDN blurs the silos between network, server, virtualization, and app teams.  It will be hard, “there will be blood”.  But it is long overdue in reality.