For those that aren’t aware, I was proudly in a fraternity in college and our motto was simple, “Loved, Hated, but Never Ignored,” and we wore it proudly on our fraternity t-shirts. The same motto seems to be true for Software Defined Networks in the industry at this moment. There is a community of folks that see the potential, but not everyone is on board, not everyone thinks it’s for real, some call it hype, some call it a technology for Cloud Providers, and some think that it was built by the academic community and that’s where it will stay for the long term, but you know what, people keep talking about it, and that’s a great thing…because you don’t want to be ignored ;). There have been many blogs, tweets, and announcements in this space with the most recent coming from Nicira.
Secondly, just today with great timing, was a BigSwitch sponsored webinar delivered and hosted by Greg and Ivan that concluded with an extremely short demo of the “Big Virtual Switch” functionality of a Big Switch OpenFlow controller. With these recent events, of course come more optimism, pessimism, questions, concerns, and even more general thoughts regarding this semi-new network paradigm.
As you examine Software Defined Networks for your network, you must ask yourself, how important is open standards in all aspects of the “new network?” Will you only use IEEE standard protocols? Will you dabble in feature-rich protocols from a new vendor that give your business a competitive edge? Will you dabble in feature-rich protocols from a new vendor that simplifies network operations and provides a finer level of network security?
These are questions that will need to be answered by all as different vendors will surely have individual SDN offerings some of which are based on OpenFlow and some of which are based on other protocols. But, in either case, there is a great chance of vendor lock-in in a Software Defined Network. To clarify, I have no issues with so-called vendor lock-in if there are benefits for the environment it is getting deployed in.
The area of vendor lock-in around SDN is very interesting. IMO, I think this was a larger topic of discussion last year when many companies touted OpenFlow to create a more vertically oriented system that resembled that of the server market: buy your switches from Cisco, buy your controller from BigSwitch, and buy your applications from Cisco, BigSwitch, Nicira, and whoever else wants to sell you a killer app.
It actually makes sense and could work, but... The issue: hardware vendors are going to develop their own controllers which will inherently have a more feature rich offering than when used with another vendor’s controller. If they aren’t developing their own controller, they will probably be in bed or at least spend more R&D with one controller vendor over another. Either way, there will probably be features supported in one hardware platform and not another. The same holds true for different types of virtual switches and other devices. You can’t expect the same controller or applications to work in any given SDN the same way.
As I’ve mentioned in other articles and Matt Davy from IU did last year in his blog, how many people have deployed an Aruba Access Point with a Cisco Wireless Controller? They both run an IEEE standard protocols. What happened? What was the drive to move off of Cisco proprietary LWAPP?
The next portion, and in my humble opinion, is the most important piece to consider if vendor lock-in really matters to you. Examine the Ecosystem available to you, i.e. how many applications can be built on top of one’s OpenFlow/SDN controller? How extensible are the APIs? How large is the team that would be responsible for developing applications for a specific controller? How many out-of-the-box applications are there or will there be 12-18+ months? If there aren’t canned apps, will you be expected to have a network savvy programmer? These are insanely important questions to answer.
Most likely, these apps that are layered on top via “northbound APIs” to the controller are really the selling point for a particular “network” going forward. You may not care what hardware you have any more if there is some kick-ass controller/app combo only offered from particular vendors. I mention 5 applications in a recent post that may or may not make sense for someone or some company to develop. Maybe they are Phase 2, 3, and 4 applications.
I truly believe that the first application may just be for increased operations of the network. Almost all of my customers have become masters of complexity. Why? Can we change that with SDNs?
After seeing a tease of a demo from BigSwitch today, where they were able to within just a few steps, create a logical switch that spanned several physical switches…you instantly wanted to see more (but didn't get it!); awesome idea! I do hope there is an Apple-like GUI to go along with it too! Again, this is a feature of their controller, but aka lightweight independent controller application creating *real* virtual switches for network isolation. The best way to explain this would be to have a VLAN span 5 switches with 4 ports per switch in that VLAN. You can then telnet/SSH into that “VLAN” and view a 20 port switch. Pretty sweet! Their demo emulated a L2 segment, but one question I have is if one tenant needed two isolated LANs and put a router in between, what would that look like from a management perspective. I’m basically looking for a VRF that I can now telnet/SSH to that looked similar to the VLAN that I previously described. Make sense?
Anyway, back to the Ecosystem. Should these northbound APIs be standardized on? I’m not so sure, but if this matters to you, investigate each solution and look at how applications will be layered on top. You need a controller that is extensible and a company will listen to your needs and work/build with you along the way. Eco-systems are not born overnight, but the underlying application architecture will offer a great deal of visibility into the possibilities of the future.
Regarding the vendors out there, I’m sure they will want some form of openness in their application and controller architecture, but is it really in their best interest to be 100% open? Wouldn’t you want some added bells and whistles for your product that will differentiate your offering? You can look at any switch today – all support standards based protocols, but if you take Cisco, they probably support 10x more advanced features that differentiate their offerings. I’m not saying everyone uses those features, but they are there and most of the time, good selling points.
There have been good articles published recently. I quite liked the one from Art over at Network World where he wrote about his interview with Nicira co-founder and CTO, Martin Casado. He draws some nice parallels to the network engineer/PBX engineer to the network engineer/application architect. Should network engineers be concerned their world is being taken over by the server and application teams? Great question. What do you think?
Finally…there have been so many marketing phrases about the network – that the network is the platform, the intelligent network, self-defending network, borderless network, etc. But, this all really does seem possible if the network is Software Defined…once many of the scalability and stability issues/concerns are all met on an individual basis ;)
Regards,
Jason
@jedelman8
RSS Feed
