INSIGHT: Examining SDN failures
- 22 September, 2015 06:23
Over the last 2-3 quarters, the mentality in many client calls has shifted from “What is SDN” to something more tangible such as “What’s the best network for cloud” or something akin.
That said, people are still very interested in SDN, but want real-world stories (or “tales” depending on your perspective).
Thus, we are asked about SDN failures or horror stories, because there’s certainly not a lot of publicly available information about that. Nobody wants to publicly display their networking failures and vendors are doing a good job keeping these failures under wraps.
Having said that, there have been some failures, but (SPOILER ALERT) If you’re looking for massive production meltdowns you’ve come to the wrong place…
Most of the failures have occurred in trial/POCs/bake-offs in non-prod. In the mainstream, production SDN deployments have been small, mostly pragmatic, and surprisingly solid (in part due to white-glove treatment from vendors).
For those who’ve implemented, the technical issues are actually standard-fare type stuff (i.e., “it’s not that different from a typical network upgrade”….but then again that isn’t saying a lot).
Typically, the biggest problem has been culture and staffing, not technology.
That said, there have been a decent amount of failed SDN pilots.
Note: I’m defining “failure” as didn’t move forward with production implementation.
In reality, a failed pilot can be very beneficial if you learn from it, but I digress… In these instances, deployments were halted before hitting production (as they should’ve been).
These failures have been pretty evenly distributed across all the big and small SDN players, no vendor is immune. The general feedback from clients reporting a failure can be categorised as:
•The solution failed at scale
•The solution was missing features (It was cool, but it couldn’t do all the things we wanted)
•The product or vendor was too immature for us (it wasn’t for ready for primetime or didn’t feel “baked enough”)
•It was too complicated or hard to implement.
Our organisation was not ready to handle SDN from a staffing/culture perspective (somehow, this scene is fitting).
Side note: Since we’re talking SDN and failures/outages here, always good to point out that SDN doesn’t fix all network outages, despite what you may read.
By Andrew Lerner - Research Analyst, Gartner