Software Defined Networks (SDNs) - A History Lesson

[Gracely's Theorem - 99% of all new tech ideas are just old tech ideas + bandwidth + faster CPUs]

I'm a big fan of history, especially technology history, because it gives us such wonderful guidance about what to expect with each new "technology disruption". Just like the history of mankind, technology tends to follow repeatable trends, actions and mistakes.

The latest trend that I've been carefully watching is around Software Defined Networks (SDNs). Today's SDN discussions are primarily focused on how new paradigms will change the architecture of IP networks and how network-level services are delivered and managed. This shift is being led by companies like Big Switch, Nicira, Embrane, and Cumulus, but it's being closely watched by incumbents like Cisco, HP, IBM and Juniper. At the core of SDNs are a couple of basic principles:

1. If the hardware and software functions of network equipment (switches, firewalls, etc.) were able to be decoupled from one another, then the industry would be better able to leverage the economics, advancements and speed of the individual components to more quickly enable new networking capabilities. Maybe new network capabilities enable new revenue opportunities (maybe...)
2. By logically (or physically) separating the Control Plane and the Data Plane, more scalable and flexible network topologies could be built to better handle the needs of dynamic, web-scale networks.
3. Technologies like server virtualization have radically changed the demands on the network (live migration of virtual machines, software based network services, etc.) and the network needs to evolve to accommodate these new application needs.

One of the promises of this new paradigm is that IT organizations will be able to buy their Control Plane equipment (the SDN controllers) from one company and their Data Plane equipment (switching hardware) from other vendors - with an implicit assumption that the hardware will quickly become commoditized (x86-based appliances or switching built upon merchant silicon from companies like Broadcom or Intel/Fulcrum). We may also see the Data Plane built on software appliances, or the Control Plane controllers created out of open-source projects. 

The possibilities sound very intriguing, but beware the big bad wolf of technology history. The road to riches and market disruptions are paved with the tombstones of disruption cycles of years past....

In the late 1990s, a decade after deregulation of AT&T (the original "big cloud"), the telecommunications (read: voice) networks were going to go through massive technology disruption as the Internet become ubiquitous and DSP technology became much more affordable. To accomplish this, many start-ups were going to disrupt Lucent, Alcatel, Nortel and Siemens by separating the control plane and data plane of the voice network, replacing it's hard-wired switches with a new IP fabric. It would be built on open signaling protocols like H.323, SIP and MGCP, which would allow carriers and businesses the flexibility to buy equipment from multiple vendors, speeding time to delivering new services. Proprietary DSP equipment would be replaced by low-cost boards from Dialogic and Intel, and controllers would be built on open-x86 platforms, in some cases with open-source technologies (note: this was 5-6 years before Asterisk came on the scene)

Hmm....sound vaguely familiar?

What Happened Back Then? What Could We Learn Today?


A couple interesting things happened:

1. Just like the 2012s, some 1990s companies claimed to be able to solve every existing challenge better than today. They could do core to edge to service-layers. Very few of them succeeded. The ones that succeeded quickly realized that they needed to find a few critical pain-points and solve them extremely well. These included high-cost areas, high-change areas, and emerging market areas - Access-Density, SS7-Offload for Text Messages and Prepaid-Calling in Emerging Markets, respectively. Lession #1 - Be great at solving a few high-value problems, not re-inventing all architectures. People will change for $$ reasons, not just technology reasons.
2. Open-Standards do eventually work together (across products), but it takes quite a bit of time and testing (read: ping-fests, standards battles). In the interim, companies get anxious that they aren't differentiated enough (add proprietary extensions) or their customers ask them to solve challenges not easily accomplished with the existing standards (add proprietary extensions). As a result, there were very, very few implementations that used equipment from different vendors in the Control Plane and Data Plane, at least in a completely open model. The vendors eventually restricted their ecosystems in order to be able to maintain feature compatibility with a few key partners. Lession #2 - Your business case might fail before the standards work everywhere. Expect early implementations to have limited (or a single) vendor.
3. For all the talk of disrupting business models, the reality is that the revenue models of both the vendors and customers remained in pretty much the same places - where services were created and delivered. So in the voice world, the money was in the controllers where services lived. The same will probably be true in networking SDNs. Lesson #3 - The early headlines might be focused on boxes, but the future money is in the control software (just like it is today). 

Amidst all the SDN announcements that we can expect in 2012, I will be very interested to watch which companies figure out their customers pain-points the fastest, and which ones establish themselves as the dominant Control Plane vendors. I suspect it will be the ones that make it easier to enable mobile applications; easier to make security seamless and robust; and those that enable the framework to allow smart businesses to create new services that be 10-100x more profitable in the new SDN models.

So be smart SDN vendors, or the big bad wolf of technology history may come huffing and puffing on your straw house...