In the previous post introducing Software Defined Networking and the philosophical camps which were influencing its evolution, I defined three theoretical points of view: The Purist, The Architect and The Establishment. These points of view, and the ways in which they blend together help us understand how the market players are motivated to improve and adopt SDN technologies. In this post, I’ll explore the three primary markets which can potentially be served by SDN and the unique requirements each places on the technology.
The obvious place to start is with cloud-scale datacenters, as these players championed the initial production quality implementations. Two primary motivators drove Google and Facebook, but also the others (Microsoft, Yahoo, Verizon, DT, etc) towards SDN – minimizing the capital expense of datacenter build-outs and instrumenting the network in a way analogous to how the server and storage infrastructure had already been. The scale and growth rate of these datacenters enabled these companies to have direct conversations with hardware manufacturers and coincided with a growing consolidation of the datacenter hardware designs to ones based on the Broadcom Trident chipset family. This consolidation along with the growing expertise of the manufactures (specifically Original Design Manufacturers – ODMs) to take complete responsibility of the product from block-diagram to finished goods enabled these companies to easily source these products as commodities, directly from the source. Additionally, these companies were unencumbered with the legacy of traditional networking companies (specifically the bewildering proliferation of protocols and standards called out in every end-customer RFP) and thus able to realize the benefit of the clean-slate approach being proposed out of Stanford and Berkley. This led to the formation of the Open Networking Foundation and the original OpenFlow specification. Over time OpenFlow has evolved to define the packet forwarding paradigm (closely mirroring the capabilities of commodity switching silicon) and provide a language for programming the databases on which that paradigm operates directly.
In many (maybe most or even all) cases, the cloud-scale players developed a custom switch OS and SDN controller to implement these ideas. While this enabled them to race ahead of the maturation of the open-source initiatives, it represents a level of investment and expertise which exists only in the largest and most technically savvy companies. In this respect one can see how the cloud-scale companies represent the blending of The Purist and The Architect points of view. Without their willingness to push SDN into their solutions, it would still be a purely academic discussion.
SDN solutions in the datacenter space can be broadly categorized into two different styles: the bare-metal style described above and implemented by many of the cloud-scale providers and overlay solutions, which evolved later. The overlay solutions leverage the existing network interconnect a black box which provides (largely) point-to-point services. The participating SDN end-points (most often the hypervisor in a virtual machine host) tunnel to each other over the black box. SDN is leveraged within the vSwitch to provide connectivity, security and service chaining. This model trades optimal performance within the network for ease-of-use in provisioning virtual machine, storage and NFV-based applications.
Next up, I’ll take a look at the Service Provider and then finally the Enterprise markets.
Leave a Reply