Menu
​INSIGHT: Examining SDN failures

​INSIGHT: Examining SDN failures

People are still very interested in SDN, but want real-world stories (or “tales” depending on your perspective).

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

Follow Us

Join the New Zealand Reseller News newsletter!

Error: Please check your email address.

Tags GartnerNetworkingCloudData Centresoftware-defined networking

Slideshows

Meet the leading HP partners in New Zealand...

Meet the leading HP partners in New Zealand...

HP has recognised its top performing partners in New Zealand at the second annual 2016 HP Partner Awards, held at a glittering bash in Auckland. The HP Partner Awards recognises and celebrates excellence, growth, consistency and engagement of its top partners. This year also saw the addition of several new categories, resulting in 11 companies winning across 11 award categories.

Meet the leading HP partners in New Zealand...
Channel comes together as Ingram Micro Showcase hits Auckland

Channel comes together as Ingram Micro Showcase hits Auckland

Ingram Micro outlined its core focuses for 2017 at Showcase in Auckland, bringing together the channel for a day of engaging keynotes, compelling breakout sessions and new technologies.

Channel comes together as Ingram Micro Showcase hits Auckland
Show Comments