SDN, It’s Free just like a Puppy!

I have written both and will post at the same time because I believe we are conflating many issues when it comes to networking.  For example: SDN, ONF, OpenFlow, Overlays, Underlays, Tunneling, VXLAN, STT, White Box, Merchant Silicon, Controllers, Leaf/Spine, Up, Down, Top, Bottom, DIY, Cloud, Hybrid, NetContainers, Service Chaining, DevOps, NoOps, SomeOps, NFV, Daylight, Floodlight, Spotlight to name a few.  Both of these posts are intended to be read back to back.  I wrote them in two parts to provide an intentional separation.

I have fantastic news for everyone who wants to implement SDN:  It is free; just like a puppy.  In many aspects, SDN is just like a puppy.  It is cute, we fall in love on sight, we want to play with it, we want to take it home, we limit its space until it is house trained, it provides us with unconditional affection and we like everything about it.  It is going to bring joy and happiness to our network, I mean our family.  Unfortunately, we have to live it and the life-cycle is going to be about 15-18 years and the puppy we have today is going to grow into a big dog that will soon stop being cute.  What we really need is a new network applicable everywhere that is on par with all the other IT technology pillars.

Taking a step back for a moment, let us review the decade of the naughts.  In 2001 we had just come off the internet/telecom bubble of the 1990s and the obscene spending on Y2K readiness.  In May 2003, Nicholas Carr writes an article in the HBR called IT Doesn’t Matter and pens a book a year latter.  The article is basically said that we will get our IT services from a great IT utility in the sky because the stuff is so complex, so expensive (i.e. CAPEX) and so labor intensive (i.e. OPEX) that the only method to control cost is to do it at scale like the power grid.  Maybe it is regulated too.  A number of enterprises took the approach that they would just out source their IT people and services to a third party.  Large businesses were built just to integrate and administrate IT at scale.  All sorts of outsourcing companies grew into large business doing the complex work of making stuff work and many companies even outsourced IT abroad.  Do you remember when we were all reading Thomas Friedman’s book The World is Flat?

When I wrote this post a few weeks ago I was thinking about the past decade of networking, but I think I can set the background better than I did in that post.  Imagine we all worked in a datacenter until the end of 2002.  In December 2002 we decided to take a year off, bum around the BVIs and then we opened a coffee shop.  Something cool like Blue Bottle in SF or Voltage in Cambridge.  After ten years the coffee bug was worked out of our system and we decided to go back and work in the data center we left in 2002.  When we got there and looked around we would be in shock.  Every element of the modern data center would be different and nearly unrecognizable from 2002, ten years ago.  Every element of the modern datacenter had dramatically changed from the servers to applications to storage to devops tools including power, cooling and the physical size of facilities.  Everything would be unrecognizable except the network.  The network would be the same.  We would recognize the network and we could probably be knowledge current in a day or two with the design and operation of the network — yet in the intervening decade the nature of applications, servers, workloads, storage and how those elements of IT interact would have dramatically changed.  I have heard this state describe in many ways:

  • Cargo cult culture
  • Network people are masters of complexity
  • Network people do not think outside of the box – they are not risk takers

Some companies have attempted to break this culture; most notably are Amazon and Google.  Amazon looked for ways to sell their excess IT capacity and this became AWS.  Google decided to build their own network equipment figuring that if the current state of the switched network is the best it is going to get, meaning we are just going to lash up bigger and bigger leaf/spine hierarchies, then they can at least make it less expensive by doing it themselves.  Around 2004 and into 2007, a group at Stanford and some of the search engines came up with the idea of separating the data plane from the control plane and trying to solve the inflexible nature of the network through programmability.  Then Nicira came out with overlays.  All of these were attempts to fix the network by logically overlaying to abstracting aspects of the network with programability.  Let me review the sequence of attempts to control network cost in past ten years:

  • Outsource
  • Lease
  • Do It Yourself
  • Overlays
  • Implement SDN (i.e. Controller Architecture) + Merchant Silicon

These are all attempts to attack the cost both in terms of CAPEX and OPEX .  Commoditization and DIY networking are really the puppy elements of SDN.  Product life-cycle management is difficult.  Components, supply chains, QA testing, regression testing, you know the six sigma stuff, is hard to do.  Subsituting one cost element for another is not really a long term solution to the problems presented by the current state of switched network designs.  I think the siren song of commoditization and DIY networking are appealing to people because the network does not really change.  That is my point.  The solution is changing the network construct — not more of the same.  Network switches are not like disks and servers.  Disks and servers are not the same either.  The cheap-and-cheerful disposable hardware model only works:

  • …for servers if workload is fluid
  • …for disks if data is fluid
  • …for switches if capacity is fluid
The word fluid is being used to as a condensation/conflation of: replicated, replicable, re-locatable, re-allocatable.  Interesting that when you think about it this way, virtualization is not a means, but a result of fluidization.  Pointedly, network virtualization does not make capacity fluid — it makes workloads fluid.  If workloads are fluid, it would be helpful to have fluid network capacities to allocate to the demands of the workloads.   

The OPEX cost of the network is not going to change until the network portion of the IT model is made concurrent with the other elements of the IT model.  What needs to be addressed is: (1) network correlation and automation that is concurrent with the state of other technologies in the DC and (2) better utilization of the network based on what is important which is applications and workloads.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s