This week, I had several surprising discussions about SDN:
I received several emails and phone calls in which I was told about the latest companies in the SDN space. They were not even referring to recent startups; they were referring to companies that have been around for five, ten or more years, but they are now listed as SDN companies or have recently changed their focus to embrace or become SDN companies.
In another conversation, one VC told me that post-Nicira, every network-related startup is an SDN startup.
I was in a meeting with a potential ecosystem partner. We had a room full of technical thinkers and the standard questions still came up:
– What is your opinion of the Nicira deal?
– Do you compete with Nicira?
– Is Cisco going out of business?
– What is the Insieme team building?
– Who is buying SDN networks?
A part of me wants to refer these questions to my blog as I think I have posted clear answers, but perhaps I am wrong. I also had a couple interactions with industry analysts this week and through all these interactions what is clear to me, is there is no agreed upon definition of SDN –it means something different to each company and each person.
I am not the first to ask or think about the definition of SDN. In fact there is way too much to link to, but here are some worth reading. See Wikipedia here; Mike Fratto here; a summary of Nick McKeown here; the ONF here; and Tom Nolle here. There is also this long post by Kevin Fogarty. I’ve pulled a few quotes from his article below because I think they highlight the confusion around the definition of SDN, while focusing on the MacGuffin travails of Cisco.
- “[SDN’s] goal is to make configuration and management of large networks simpler and more flexible by letting network managers define capacity, membership, security, usage policies and other functions using software that doesn’t care who made the hardware it’s reconfiguring.”
- “SDN is still a nascent technology. Definitions are still flexible, and the percentage of adopters is still in single digits…”
- “What’s certain is that, in the long run, hardware is simply hardware. Neither network managers nor end users pay Cisco to truck over yet another big box to sit in a data center, sucking up power and blowing off heat.”
In regard to the three quotes above, I disagree with #1 and #3 and agree with #2. Last week I posted my thoughts around a definition for SDN. I am now expanding on those thoughts. When I think about SDN, I think about software. Not the software that operates on the network element, I think about the software applications that use the network. I think this concept is the source of many misguided thoughts in regard to the network and the networking industry.
Simply putting some sort of API or programmable interface in a network platform and calling it “software defined” is not really helpful. What would be helpful is if software applications that use the network can communicate with the network and define the network based on the needs of the application. That is what I consider a software defined network. The software that uses the network defines its network requirements and communicates with the network to orchestrate the network based on its needs.
The limitations with the network today have very little to do with programmability. The problem with the network today is it is fixed and cannot be easily reconfigured to meet the changing needs of applications and workload placement. This is also a point of confusion. I hear people say “don’t touch the network, it works just fine” which is true if you are thinking of the network as sandbox in which others cannot play. The reality is that most networking people do not want to tell you or perhaps they have not accepted that the very nature of networked applications has dramatically changed over the past decade.
Another way to think about it is in terms of the fundamental interconnectedness of all things. Server virtualization, modern application architectures, multi-tenancy have taken formerly separable IT disciplines and forced them to be tightly inter-related. Meanwhile the network has stayed basically the same. Networks need to learn to play nicely with others.
All the people who think hardware is just hardware and it is going away are sadly mistaken. I am not really sure how the white box hardware meme started, but it is grounded in some historical fact and it has been poorly applied to the future. It is true that in the past some large firms with financial means and smart people realized that they could build a network switch from the same silicon that current networking equipment suppliers were using. These companies were able to do this because the architecture of the network has been the same since we left the world of shared LANs. This white box event has been mistakenly construed as a sign of the future, when it is really a sign of the end. We are at the end of the switched network era and the white box event was really an entry point to a period of recomposition that began five to six years ago. We are beginning a new architectural era in networking. Accept it.
The era of hardware innovation is not over – it is just been sputtering because the network has been caught in a loop for twenty years. If I was to draw a typical network design (i.e. leaf/spine, CLOS, switched, 2-3 tiered, etc.) I could make the design operational with products from 15-20 different vendors. Each vendor has some element of differentiation, but the network is and has been the same for years. I would describe this as a standardization success story, but personally I would like to thank the iPod, iPhone and iPad teams for not accepting hardware standardization. Not building white box MP3 players, mobile devices and tablets worked out well for them.
What we have been doing is racing down the latency curve and the port density curve. That is another sign of the end. We have pretty much reached the long tail of the port to port latency metric and there is not much reward going forward for being the 40G or 100G port density champion.
The unspoken reason why a few select companies with means left the networking rival tent to build an in-house designed network switch is because it was the last viable strategy to achieve a level of capital savings. It is a sign of the end of the switched era – not a sign of the future. Deal with it.
The concept of SDN does not mean that networks are sans hardware. That idea is just some silly hyperbole. SDN does not mean that we can now program the network. In my view, we program the network today. I set up a bridge and router for the first time in 1988 and I’m fairly certain we have been defining capacity, membership, security and usage policies for a long time. I will conclude with what I wrote last week. There is a lot of confusion around what SDN is or is not. I think we are talking about the evolution away from distributed protocols and fixed network configurations. Other people think we are talking about some level of network programmability. In my view, a software defined network architecture means the allocation of network bandwidth is computed as a system (i.e. pooled) resource by controllers with a broader view of the application needs.
If you are attending VMworld and want to discuss, I will be standing in the Plexxi booth #312. Stop by.
If you are a new reader to my personal blog, here are a few related posts on SDN from the past six months. I referenced previously addressed concepts above from these posts:
– June 26, SDN Max Hype
– June 1, SDN Thoughts
– May 20, New Network Meme
– April 24, Missing the Point on SDN
/wrk
The post Working thoughts on SDN #2 appeared first on Plexxi.