7 Common Misconceptions about SDN (2015 Edition)

Over the past year, SDN awareness has skyrocketed in the mainstream. Most organizations are aware of the technology and now have plans to at least evaluate it. That said, there is still some confusion around the technology, and here are the top 7 misconceptions we see, versus last year.

#1 – SDN is just for cloud and service providers  

This was and remains the number one myth over the last 12-18 months. While the early SDN adopters have been cloud providers and folks with large-scale networks, the benefits of SDN (agility, cost, management, innovation) apply to the mainstream, and even midmarket.

Related research:  Beyond the Hype: SDN Delivers Real-World Benefits in Mainstream Enterprises and Midmarket Context: ‘Three Key Challenges to Resolve Before Deploying an SDN Overlay’

#2 – SDN is for the data center only  

While much of the SDN talk is in/around the data center (“Hey, I can spin-up VMs in minutes why does it take a week to get network/firewall changes“), SDN has applicability in the WAN and Campus as well.  The WAN in particular is a pain-point for many clients as it often takes weeks/months to get bandwidth provisioned and it is very expensive. Not to mention that enterprise bandwidth doubles every 2.9 years and managing hybrid WANs is difficult.

#3 – White-Box Switching is SDN 

This holds steady at #3 from last year.  You can do white-box (and brite-box)  with and without SDN, and vice versa.  They are related in the sense that once you move intelligence to the controller, you need less feature capability in the hardware. But people can (and certainly are) doing them independently of one another.

Related research: The Future of Data Center Network Switches Looks ‘Brite’

#4 – SDN is the only path to network agility 

To date, the “killer use-case” for SDN has been data center agility. SDN can certainly make your network more agile.  However, there are multiple paths to agility, including automation, orchestration and programmable fabrics.  Also, don’t get me started on the fact that the value of SDN is way more than agility.

#5 – Programmable Fabrics are SDN 

This is a repeat form last year as several vendors offer programmable Ethernet fabrics (often with APIs) that are commonly referred to as SDN.  These are often very nice products that solve real problems.  If you’re building a new DC network, we’d recommend you go with a fabric. That said, fabrics are not SDN.

Related research: Ending the Confusion About Software-Defined Networking: A Taxonomy (which we are in the process of refreshing) and Technology Overview for Ethernet Switching Fabric

#6 – SDN is just a network upgrade 

SDN is not something you do in a 3-day weekend.  It is not something you slather across the environment.  SDN is an architectural approach, and we’d recommend you deploy it opportunistically and pragmatically associated with business initiatives/needs.  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 like the public-facing website (i.e., scale/resiliency).  Then, it became a standard to deploy new user-facing apps behind the load-balancer moving forward.  Think of SDN in the same manner.

Related Research: Mainstream Organizations Should Prepare for SDN Now

#7 – Programmers will now own the network

Network folks tend to get a little twitchy when they hear that SDN allows “programmatic access to the network”.  When combined with reports of DevOps proliferation, the typical response from folks with operational network responsibility is “The last thing I want is developers controlling the network”.  However, SDN is not the wild west.  Application folks can write APIs to the controller via pre-defined templates or blueprints.  These templates are typically setup by a Networking person.