Networking Field Day 5: SDN and Unicorn Blood

So, we wrapped up our day with the Networking Field Day crew last week with a free form discussion on where we go next with SDN.  To be honest, the session did not go quite as I envisioned, but, in retrospect, I would not changed anything.  As Ethan Banks (of PacketPushers fame) noted in Twitter, this session was more about shooting the unicorns than letting them run free.  It seems that if we are going to convert our SDN unicorns into SDN plough horses, we are going to shed a little blood.  At the end of the day, the market will be served by frank conversations—we need to move beyond painting SDN acolytes as starry-eyed and SDN detractors as being heretical and reactionary.

In the interest of keeping the conversation going, here are some of the things I walked away with after the conversation on Wednesday (in no particular order):

Is Hardware Innovation is Over?

This industry has always been one big pendulum and, currently, the pendulum is firmly in the software camp.  Today, many of the truly interesting things in networking are going on with software.  While most would agree we are at an inflection point with programmability, there are no clear directions for the evolution of SDN.  Certainly there are pieces in place like OpenFlow and OpenStack, but OF 1.3 in unlikely to be the zenith of OF evolution let alone SDN evolution—current technologies will continue to mature and new ones will inevitably emerge.  More importantly, the “how we do things” and “what do want to accomplish” of SDN will most certainly continue to evolve and as long as that is the case, software will rule because it’s simply easier and faster to experiment with software.  But, once some clear directions begin to emerge, I guarantee you the action will swing back towards the hardware because doing things in hardware tends to be faster and more efficient.  I could point to Cisco examples of this, but instead look at what Intel, the poster child for general purpose processors, has done with VT extensions to support virtualization or QuickSync for video transcoding.

Is OpenFlow Ready for PrimeTime?

One of the more contentious points yesterday is if OpenFlow is production ready.  I think it’s a flawed “do these jeans make me e look fat” kind of question.  There are certainly folks out there using OF to handle production traffic—for example, some of the cool things Brent Salisbury is doing.  So, it’s not a binary question, but more a matter of assessing scope and scale. The better question to ask is what is the operational and performance envelope of OpenFlow and how does that match my needs, priorities, and capabilities. The risk with any emerging technology is that, often, the only way you find the edge of the envelope is once you’re on the other side, usually with colorful and memorable results. Regardless, I don’t see this question existing in another year or so.

Applications Only Grow in One Direction

I think we can agree that software systems tend to increase in complexity over time—when was the last time a new version of software had less features and fewer lines of code than the prior version.  I feel confident that folks can peel of specific functions and capabilities and handle them with OpenFlow or whatever.  As folks look to build on their successes, I wonder what this all looks like in 5 or 10 years—I am not assuming it all ends badly, but I also think it would be naïve to assume networking software projects would be insulated from the traditional challenges of other long-term software projects.  You are slowly migrating functions that came in your network OS (or you wanted to come in your network OS) from your vendor to yourself.  Along with that control, you are transferring cost (from capex to opex) and risk (the Pottery Barn rule—you broke it you own it).  Again, not inherently a bad choice, but it should be an informed choice considered against a meaningful timeframe.  I think the conversation needs to pivot from “can we” to “should we”—is it cost-effective, is it expedient and is it sustainable? Perhaps the ultimate irony of all this is that after decades of complaining about developers, folks suddenly want to become said developers.

What do Customers Want?

The flippant answer is they all want something different. 🙂 SDN is interesting because it is generating a lot of interest but it also seems to run counter to the trend of customers getting more disentangled from infrastructure with solutions like Vblock, FlexPod and OpenStack or even more so with the myriad public cloud offerings out there. So, I firmly believe the vast majority of customers (unless they happen to be building those aforementioned cloud solutions) are not looking for some commodity silicon and a handful of primitives.  That is the networking equivalent of the “C:\>” prompt. Instead, I think what most folks are looking for is an abstracted and approachable way of manipulating traffic flows on a selective basis.  I don’t believe most folks want to go hand wire basic networking functions they take for granted today like stable L2 and L3 adjacency—no one is out there looking to code a new version of root guard and even if they are, they are going to have a hard time convincing their management it’s a good use of time and money.   I also don’t think most folks want to hand wire every flow that crosses their network.  I do think folks will want the option to exert a high degree of control over certain applications, functions or services that particularly matter to them.  To that end, I think we are heading in a good direction, but still a bit too much in the weeds—we need to get to a point where network resources are presented and can be manipulated in a way that a developer might think about things—and I don’t think we are there yet. I expect things to grow in a couple of directions: 1) emergence of approachable abstraction models that allow intuitive manipulation of network resources by non-networking geeks and 2) availability of applications that sit atop an SDN framework (in our case, either onePK or our ONE controller) that customers can buy that provide specific functions or capabilities–giving them more granular control without getting grease under their fingernails. Anyway, at the end of the day, choice is good and folks should be able to bite off as much as they are willing to chew.

 

One last thing…I see this whole concept of programmable infrastructure as an immensely powerful concept, but I have to be honest, if all we manage to do is build a better load balancer or find better ways to provision VLANs, while no doubt useful, I think we will have really missed the mark.  I think the really innovative stuff is still out there.

By the way, if you missed the live feed for the SDN discussion here it is:

You can also check out the earlier sessions on onePK, using onePK and Puppet  and the ONE Controller.