What Can I Get From A Software-Defined Network?

SDNSummer has officially ended, and that means a few things: Baseball has reached the exciting time of the season as the playoffs are now underway; the NFL is a quarter season over, and the NHL has just kicked off. In the tech industry it’s time for the fall edition of Interop held annually in New York. While not as exciting a show as its spring counterpart in Vegas, this year’s fall Interop was highlighted by the return of Cisco CEO John Chambers, who had been absent from this conference for the better part of six years.

The Chambers keynote — as well as every other keynote — was focused on ‘software defined networks’, although Chambers did refer to ‘hardware defined networks’ as well. Given the relative mania around SDNs this wasn’t all that surprising. Listening to the different keynotes, though, it got me thinking about some questions: what do software defined networks mean, and what problems do they solve? The answer is… well, there isn’t a single, universal answer to the question. For example, Cisco’s SDN, or HDN as they call it, has to do with provisioning. However, some vendors consider SDN to have broader WAN implications. Others may look at the programmability elements of SDNs.

In my mind, these are the primary functions of a Software Defined Network:

  • Data center provisioning. This is where many vendors have focused SDN efforts. Provisioning data center resources can take a very long time with legacy infrastructure. SDNs enable the orchestration of IT resources up and down the stack. In fact, full IT orchestration, from hypervisor through network, is the main functionality that Insieme will bring to Cisco when it is “spun in” later this year. Delivering on “point and click” provisioning isn’t easy, though, and is one reason why the industry has seen a rise in converged infrastructure, including Cisco’s UCS, EMC’s VSPEX, HP’s FlexFabric and Lenovo’s converged stack. This gives customers the ability to have the benefits of rapid provisioning without having to stitch the solutions together themselves.
  • Traffic engineering. The ability to control a network through software creates the ability to better manage traffic across a network. A bandwidth intensive application could manipulate how traffic flows through a programmable interface. A good example of this is the recent announcement by HP regarding Microsoft Lync, where the application has greater control over a how the UC traffic flows over the network, optimizing performance. Of course, there are many other ways to do this — including MPLS, QoS, CoS, and WAN optimization — so using SDNs to do this may take a while to catch on.
  • Programmable infrastructure. This hasn’t been in the media as much as it used to be, but it is certainly a viable use case for the right type of company. If you’re Facebook, Baidu, or Google and you have hundreds of PhDs running your network you should look to buy white box switches, write your own operating system, and create custom features to give yourself a competitive advantage. If you don’t have that kind of engineering talent then you may want to stay with tried and true infrastructure. A good alternative to this for less sophisticated engineering teams is to look at the rising batch of “white box” start ups such as Pica8 and Cumulus that offer a lower cost box but still have a proven operating system and some technical support.
  • Network overlays. One might look at this and say it’s traffic engineering, which it is, but it takes the concept of separating traffic to the next level. With true network overlay there is no sharing of traffic, policies, management, etc. This use case would be ideal for a large organization that wants to implement some kind of shared services model. For example, with legacy technology a city government would have a separate physical network for the fire department, city workers, police, etc. An alternative could be to build one physical network and then provision virtual overlays where each network administrator would think their network was a completely distinct one rather than a shared one. The risk here is that all of these underlay and overlay networks become “ships in the night”, and the lack of visibility across networks creates a troubleshooting nightmare.
  • Network function virtualization (NFV). This type of “software defining” is likely to have the most rapid uptake with mainstream enterprises and service providers. Today, provisioning multiple functions at a single point in the network is harder than being a NY Jets fan — it requires multiple appliances, each with their own management interfaces and UI. With NFV, one could deploy a single box and just “turn on” a new service when required. Silver Peak’s virtual WAN optimizer, Citrix’s virtual ADC, and Adtran’s virtual WLAN controller are good examples of this.

SDNs are certainly starting to look like a Baskin Robbins menu, with all the different flavors. Before embarking down the path of choosing a flavor, be sure to fully understand what the biggest pain points in running the network are today. This will help align “SDN”s with your specific network environment.