For some time I had the believe that you could let EMA write what you want, as long as you pay for it. At least with this post they show that such is not the case. EMA underwrites what I have been afraid of for a long time: vendor dependant SDN, which means lock-in.
Cisco is providing their version of network programmability through a series of APIs, controllers, and plugins. It’s clear that Cisco does not completely buy into the notion of “separating the control and data plane” which to many translates to moving networking functionality onto less expensive commodity hardware platforms.
Here you go, Cisco’s strategy is to sell hardware. If they need to add some software to it, so be it. So when every company tries to fit in the SDN-hype, i.e. SDN-washing, you get what we have seen with the term “cloud”:
SDN has rapidly become an overhyped term and one that everyone is looking to turn to their particular advantage. In doing so, the term itself becomes meaningless.
Lastly, Cisco, but also Openflow, do sell you a set of API’s to control your network. Just like you had with the CLI, but now centralized. You, as a company, have to build your own tools to talk to that API.
None of this stuff is out of the box, plug and play ready for the average enterprise … they will wait until product developers tie together the pieces and leverage the APIs to build/productize/support orchestration middleware that can fully take advantage of these new flexible network architectures.
Without tools on top of these API’s SDN and Openflow are useless for the mass market. Only a small niche can get the benefits that centralized control can provide.
A very good and constructive post by the EMA with the conclusion that SDN is going to be fragmented with my translation that interoperability will be far away. The other conclusion is that there is going to be a huge market for third-party tooling, like ours, to offer applications on top of the network API’s.