Though “data center” begins with the word “data”, everyone knows that the king in the data center is really the application. And to deploy apps, corporate IT has three main care-abouts:

  • Deploy apps rapidly
  • Simplify operational complexity (reduce opex cost)
  • Reduce infrastructure cost (reduce capex cost)

Unfortunately, the network has turned out to be the main bottleneck across all three care-abouts.  To get the network back in the “app game,” industry’s answer has been Software-Defined Networking (SDN).  However, SDN’s traditional control-plane/data-plane separation architecture (call it SDN 1.0) has had customer adoption challenges despite a ton of experimentation.  Why is that?  By peeking into the compute world success story, some clues start to emerge:

SDN 1.0 Compute Virtualization


Clearly, the SDN model is a lot more convoluted compared to the compute model – SDN SW is not in full control of network HW, and portion of SDN SW comes from networking HW vendor.  No wonder customer adoption of SDN 1.0 is slow!  I suspect these short-comings also drove some SDN vendors towards host-based overlays.  Unfortunately, separate control/management planes for overlays and underlays does not really reduce network complexity.  Conversely, it adds complexity by requiring gateways to  connect physical servers, physical routers and L4-7 service appliances.  It increases complexity in trouble-shooting, creates lack of visibility, and increased divisiveness across server and network admins. All of these create major operational and organizational barriers to adoption of overlays.  The network is certainly not new to overlays (or tunnels), but network-unaware overlay is not necessarily the answer.


So the question still remains – can network get back in the “app game”?

SDN Framework Comparison
SDN 2.0: Making network relevant to applications

 


Based on insights from the compute world, let’s consider few adjustments to SDN (call it SDN 2.0):


SDN 2.0 Compute Virtualization
In SDN 2.0, the SDN controller completely controls and manages the entire network HW topology, through the thin SDN OS.  It controls ports, power, fan speed, link lights and can fully program networking ASICs.  No longer it is limited to a small TCAM table for programming flow entries.  Of course, the SDN controller centrally controls and manages not just one network HW box but a pool of networking boxes – for example, an entire fabric of many leaf and spine switches and even virtual switches.  It provides logical network abstraction to IT administrator for writing application policies, and maps them to available networking HW resources (such as VLAN, VXLAN, MPLS).  The controller’s north-bound APIs allow integration into automation tools, such as OpenStack.


Moreover, SDN 2.0 naturally drives HW/SW disaggregation in networking.  Customers purchase bare-metal switches from a networking HW vendor, and purchases SDN 2.0 solutions from a networking SW vendor.  Customers can then independently swap out networking HW or SW (like in the compute world) – thus significantly lowering capex costs for both HW and SW.
Net-net, SDN 2.0 has the magic to get network back in the “app game” because it is:

  • Friendly to apps (deploy apps rapidly),
  • Friendly to IT staff (significantly reduce opex cost),
  • Friendly to IT wallet (drastically reduce capex cost). 

No longer, do network admins need to take a back seat during application deployment discussions.  They can stand shoulder-to-shoulder with server, storage and/or cloud admins and offer innovative solutions based on business need.  SDN 2.0 gets the network back in the “app game”!


Ok, so if SDN 2.0 has all the ingredients to accelerate customers’ adoption of SDN, can anyone do a real-world test drive?  Absolutely.  Big Switch’s SDN cloud fabric beta is a great example of an SDN 2.0 solution.  It consists of Big Virtual Switch (BVS) application with built-in Controller and Switch Light OS (Switch Light physical for bare-metal Broadcom switches and Switch Light virtual for KVM).  It provides single admin pane for the entire fabric (physical and virtual), no complex networking protocols to deal with, no box-by-box manual configuration or debugging to dive into, fully API driven & programmable & open – all on commodity bare-metal/white-box switch hardware and open-source KVM hypervisor.  Add OpenStack automation and viola! – you have a private cloud with the simplicity and cost structure similar to Amazon EC2, at enterprise-level scale and IT skill-set.

Prashant Gandhi
Big Switch Networks Vice President of Product Management