Working Thoughts on SDN #4: Relieving Workload Placement Constraints

I have been on the road making sales calls for Plexxi.  I am still amazed at the effort being put into the discovery of SDN use cases.  I was going to tweet the other day that I had found the perfect use case for SDN “fixing the network,” but self-restraint won the day.  There is a lot of FUD in the system presently and it leads to statements such as  “the most common use cases for SDN will be in network monitoring and provisioning as an added value.”  If that is SDN, I am going home.  Luckily, I have done 60+ sales calls selling solutions that encompass elements of SDN and I can say with 100% accuracy that no potential customer has ever taken a few hours out of their day to talk to me about network monitoring and provisioning.  Maybe network monitoring and provisioning are a compelling use case for SDN, I am just stating that I cannot secure a time commitment from a potential client to talk about that subject matter.  I am not critical of people thinking that SDN is about network monitoring, because I know if enough people say that is what SDN is and they keep repeating it, many people will just assume that is what SDN is.  The SDN Central site lists a number of SDN use cases, but these are high level, thematic type applications and I have found that starting a customer presentation at this level triggers a Gong Show moment.  What customers do take time out of their day to talk about is fixing their network.

Here are two simple network diagrams.  Yes they are generic, but I have now had multiple customers draw both diagrams independent of each other in a Close Encounters of the Third Kind meme.  I tried to keep the before and after in the diagram simple.  The problems that customers are trying to solve are many, but at a high level they are:

• Complex series of hierarchical network steps
• Adding new infrastructure means adding new switches, new cables and configuring network
• Workload placement inflexibility
• Low OSR (<2:1) or 1:1 OSR
• Uniform latency budget arose the network as a system
• Better programmatic control
• Complex and fixed wiring

As one customer told us and I am paraphrasing, but not taking liberties with their words “we try to keep the network as flat a possible, but we have many customers in our network and the network is always changing.  We are adding services (i.e. apps and user groups) all the time and try to keep clients and services physically connected close to each other, but as the network grows it develops a workload placement constraint.  We run out of capacity and add switches in physical locations that are undesirable or we start hanging switches off switches to create work groups and the whole thing becomes a wiring and administration mess.”  Customers I speak to want to use the concepts cloud computing, but they want it to be an internal cloud.  Customers talk to me about keeping silicon hops to minimum, keeping compute elements close to each other and building flat networks.

A few months ago I wrote about trends in low latency and networking.  I described an evolution in thinking that I was seeing in the market from port to port, pin through and switch to switch to viewing the network as a system and designing for a latency budget of ~1µs across the network.  Elaborating on this statement, I have had network design sessions with customers who want to have a network with 500, 1000, 5000 and so on, 10G servers in which the latency is always ~1µs from any point in the network.  I call this objective the: drive network OSR to 1:1, deliver a consistent latency uniformly across the network and make physical expansion of network capacity easy.

The SDN use case that customers most often communicate to me about is removing the physical limitations of their workload placement constraints.  I once used the analogy of a fragmented disk drive to a customer and it resonated.  The physical placement of switches, servers, applications and network flows become fragmented over time, constrained by the fixed wires in the network.  Customers want a flexible and dynamic physical topology.  They want simplified cabling, linear scaling and they want to orchestrate the network configuration with a Controller architecture (that is part of the SDN theme).  Combining a controller architecture with a dynamic physical topology becomes a powerful solution set.  I think the value of SDN is missed when people think of it in terms of the SDN parts.  Building a cheap ethernet switch, a controller or logical overlay as an isolated entity is not powerful.  Combining all the elements of an SDN network (switches, controller, dynamic physical interconnect, logical overlays) is powerful — individually they are not as interesting as they are in a team.

As always this blog entry is just some working thoughts.  I could be wrong, I could be correct, or misguided, but this is what I think today and overtime it will be interesting to see how networking develops.  My views are from the field and reality for me is when a customer sees value in something you have developed.

/wrk