SDN Reflections on the London Gartner Data Center Conference – Part 1

Last week I was in London for the Gartner Data Center Conference.  As always there was a wide range of interesting topics being discussed, all very useful.  Working in Cisco Data Center Services, I am interested in many data center topics, however this year I was interested to hear perspectives on SDN, how the market is evolving, and how the attendees – including many senior IT practitioners – are considering SDN adoption.

From a Cisco perspective, we were showcasing the recently launched Application Centric Infrastructure (ACI), which generated a lot of interest.  There is growing awareness among our customers that ACI could do for networks and applications what the Cisco UCS has done for the server market (with UCS server profiles in the latter proving a good analogy to help customers understand the potential of ACI).

So what were some of my key takeaways from the SDN discussion I heard here?  And what were the questions that in my view are still not being discussed sufficiently across the industry?

I expected the SDN session at the conference to be standing room only, however I was a bit surprised to see empty seats in this particular session.  It may have been the 8am start the day after the “solution showcase” (aka vendor party night 🙂 ), however this probably reflects the (lack of) maturity of SDN – the overall recommendation was that customers should start investigating where SDN may help  them, as opposed to firm recommendations to head into production deployments.  The prevailing view I picked up at the conference is that in general, SDN is not ready for prime time – but is definitely a technology to start planning for.

So … what major themes from the SDN discussions will I start with … oh, there is much to discuss!!

Do You Need SDN – or are Network Programmability and Agility Your Core Needs?

When I hear from the industry “You need SDN”, I ask, “What problem(s) are you really trying to solve?“.   For some customers, network programmability is the key problem to solve, in order to develop advanced networking use cases – for example “business rules” or “time-based” routing (useful if a major storm approaches one of your data centers).

We hear others saying they need to provision their networks faster.  This is an interesting one, since in my 10 years working in Cisco network management, I came across a large proportion of customers who rejected GUI based network provisioning (which does deliver increased productivity in network provisioning) because they (or at least their ops teams) “wanted” to use CLI.  So is the need for SDN being driven by the general failure of the industry and our customers to push and adopt (respectively) the most efficient tools already available for managing networks?  I have seen multiple “hype” arguments by our competitors saying you need SDN to address the network provisioning challenge, when in some cases good network management tools are already available that solve some of these challenges without the need to re-engineer your network with SDN.

My take on this one? As you start on SDN, make sure you consider the “Use Cases” that will help your business.

SDN and  the Gartner “Hype Cycle”.

I really like the Gartner Hype Cycle approach to describing technology adoption.  Like Geoffrey Moore’s “Crossing the Chasm”, it recognizes that new technologies may – and usually do – hit “speed bumps” and pain points on their way to adoption.  Gartner clearly recognize that by placing SDN at the “Peak of Inflated Expectations” and cautioned the audience to expect “The Trough of Disillusionment” as issues are uncovered when the technologies start being used “in anger”.  As I described in my early SDN blogs, SDN is hyped by too many without recognizing the challenges ahead.

SDN Deployment Models

Gartner showed 3 SDN deployment models to help describe the options available – device-based, overlay-based, and hybrid.  My interpretation of these models is that device-based includes pure OpenFlow, overlay-based includes the likes of Cisco CSR1000V and VMware’s NSX, and hybrid includes a mixture of OpenFlow and traditional networking, which is being promoted by several vendors.

I have some challenges with the hyrbrid model in particular.  My challenge with  this model is that its definition is rather broad: quite a few of the quite different SDN approaches around fall into this “hybrid” approach – so for example Cisco’s  onePK, ACI and even the OpenFlow or Open Daylight Controller could fall into this model (the latter when combined with traditional networking).  For me at least, this generic “hybrid” categorization doesn’t recognize the significant differences and advantages that onePK API and ACI can bring to customers considering SDN.  For example, while onePK may not be a “controller-based” SDN mechanism, it most certainly does offer network programmability and agility (see my previous section “Do You Need SDN … ” above).  And the critical attribute of onePK that is often overlooked is that it will work with the (Cisco) network equipment you have today – without the need to re-engineer your network, re-write your fault management interfaces to the network, and write lots of software to support an OpenFlow/SDN apps approach.  This attribute in particular did not receive much (in fact any) commentary at the conference, despite the obvious (compatibility) benefits for many of the attendees.

My advice on this one? – make sure you consider all SDN approaches and don’t get side-tracked by equipment vendors who think that “SDN = OpenFlow”.

I have some other key observations I’d like to share, in particular on my observations on ….

1. Overlay-Based SDN – and the questionable assumptions being made by others in this area (good for Gartner for calling these out!)
2. The SDN Vendor Explosion Challenge,
3. The “Unspoken Costs” of SDN Deployment, and
4. The “How” of SDN is still missing.

… that I will keep to my next blog.

In the meantime, Cisco Services are well versed in the challenges above, and we are best placed to advise you on your SDN journey.  With skillsets and products in OpenFlow/Open Daylight, network API (onePK), ACI and virtual network overlays, we are one of the few – if not the only – vendor with such a broad approach to SDN.  And we don’t forget that there may be other ways to solve your networking problems without the “rip and replace” mantra that other vendors are in fact advocating.  So please do get in touch if you need help to figure out how best to exploit the potential that SDN and Cisco ONE offers you.