I work in the enterprise market, mostly with routing&switching, wireless, security products from multiple vendors. I have no SDN/cloud/ISP real experience yet. My views here are based upon meetings with vendors pushing SDN solutions and fellow engineers who shared experiences, doubts and some labs to test the products.
After attending a few SDN presentation of various vendors I’m starting to make an opinion about SDN myself. Here’s what I got so far.
The current network infrastructure elements are:
[HUMAN] – [SOFTWARE/IOS] – [HARDWARE]
that includes for each element:
[ERROR] – [BUG] – [FAULT]
What SDN looks like in comparison:
[HUMAN] – [GUI] – [NORTHBOUND API] – [SDN SERVER/CONTROLLER] – [SOUTHBOUND API] – [HARDWARE]
Whoever is responsible for the network operations is worried about:
[ERROR] – [BUG] – [BUG]– [BUG]– [BUG]– [FAULT]
The elephant in the room: is SDN error free?
We can’t get rid of all possible human errors but you can move your trust from one human (operator) to another human (developer).
SDN means to trust the GUI/APP to perform all the consistency check and input validation to reduce the human(operator) error and its blast radius.
I can imagine many examples of checks to perform, something like
WARNING: The VLAN interface you're trying do delete has traffic running through it, are you sure?
Deleting default route will make the device unreachable, you better think twice before doing it.
or as last resort a sort of “I’m sorry Dave” feature that requires higher privileges to override.
But what about the GUI/APP bugs introduced by… the other human(developer) errors?
I recall a test in a vendor lab just a few days ago: I create an object, modify the object and then delete the object where object = [vlan, acl, network], it doesn’t really matter.
For some reason I did something wrong but the GUI accepted it. The app expected to delete the objects in a specific order (childs to father) that I didn’t follow (bad me!).
The SND GUI shown no error messages or warnings but in the end I needed to use the CLI (yes, SDN sometimes has a CLI) to delete by hand all the connected objects and restore the initial state that can be managet by the GUI.
It’s all about trust a.k.a. moving risk
Leave apart for now scalability, automation, speed, repeatability, readability of SDN solutions. Let’s talk about risk.
SDN is about reducing the risk of human errors and trust the provider of the SDN solution. At most SDN product presentations I see many MVP (Minimum Viable Product) and then claims like “whe have API” or “build your own app”.
What if I don’t want/can build my own app?
Who’s SDN for?
SDN right now looks a solution for ISP and big software companies with lot of developers that want to run infrastructure as a code.
ISPs right now are more interested about SD-WAN that is a different thing than SDN.
Take Betfair for example, one of the most advertised case studies of Nuage. That’s a company more similar to Netflix and Facebook than the typical enterprise. They have lot of developers and to run the infrastructure via software is most likely the better solution for them.
But how many companies have the same needs and resources? Not the typical enterprise.
Let’s talk about Enterprise? (the european size)
An enterprise has some basic needs:
- uptime and reliability
- reduce cost of operations
What an enterprise wants:
- a finished product with clear cost, roadmap, support
- a vendor to blame/get rid of in case something goes wrong
What an enterprise does not want:
- take risks
- develop it’s own SDN GUI/APP
Current SDN solutions imho do not fit enterprise needs (yet).
But we have plenty of apps!
What I like as a system integrator
One answer: NFV a.k.a Network Function Virtualization.
NFV can be seen as a bridge technology that can be implemented today and creates a strong base for the large adoption of SDN tomorrow.
Italtel and Cisco are working together to standardize NFV and maybe in the future “F” in NFV will be just an App you can install in any commodoty/white box hardware you like.
My 2 cents
I noticed in the Cisco Champions newsletter that Cisco has a DevNet conference coming in May.
The current aim are the network engineers that are supposed to become all developers in the near future (they will not). The common *“CCIEs will be useless soon” fud is not working anymore (except for authors of Pyhton books).