CenturionStudio.it - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

The case against SDN implementation

Networking expert and SDN enthusiast Patrick Hubbard plays devil's advocate, arguing against SDN implementation and exploring why it may be a bad idea.

If you're reading this, it's probably safe to assume you're following the topic of software-defined networking (SDN) and are likely eager to see broad SDN implementation. Full disclosure, I'm also a huge proponent of SDN, as evidenced by the past guest posts I've written covering its challenges, as well as its considerable potential to transform the way we deploy and manage our networks. But in some corners of IT, I'm seeing pushback to the core premise of automation. And so we must consider the possibility that SDN adoption isn't an obvious slam dunk. To play devil's advocate, what happens if organizations just say no to SDN?

Cautionary Tale of IPv6

Believe it or not, IPv6 was once the next big thing. It would not just address an IP address allocation problem, the thinking went, but would also surely revolutionize our networks. Networking pros spoke to management, built labs and developed plans for deployment. Why then didn't IPv6 succeed? Why did network administrators collectively fold their arms, lean back on their 10 dots and skip a hype cycle-driven deployment effort?

The answer is that the undertaking was just too big, and it invited naysayers -- a challenge SDN implementation might share.

IPv6 deployment isn't for the faint of heart. It's everywhere, from the core to desktops to Web servers. It creates duplicate security vulnerabilities and involves gateways, tunneling and legacy protocol encapsulation.

Sound familiar? With SDN you have many of the same challenges, but even more. For example:

  • New political considerations. What will happen in your organization when SDN implementation leads to the reallocation of network administration controls? What happens when central IT sits down with local admins to assimilate their business function?
  • New security worries. Attackers are already causing havoc, or at least are driving considerable spend, with the distributed administration and oversight model in place today. What assurances does SDN provide management that replacing admins with distributed controllers will not further increase risk?
  • New management technologies. Despite the generalized IT grumbling when a conference room projector bulb is blown, we've actually become pretty proficient at delivering quality user experiences. Our management and monitoring systems keep us ahead of most issues and increasingly proactive. Why should we walk away from billions of dollars in network admin capital -- and decades of knowledge -- to switch to managing with a GUI, like the rack teams did with vSphere?
  • Yet another new complexity. IT directors and managers are already struggling with IT buying decisions because they don't have time to keep up with the rate of change. More and more, buyers don't have expertise to weigh long-term benefits based on past experience, and in some cases, must cling to established approaches. In some ways, our excitement for SDN as technologists makes IT directors and middle managers even more wary. More than one IT middle manager has been known to mistake our enthusiasm for a harbinger of breakage.

So, while it's true IPv6 is a one-trick pony compared to SDN, they both offer plenty of hooks for reluctant IT management to hang objections on. And in pan-enterprise projects, that's often all that's required to stall adoption. It's just too easy, or even tempting, for casually connected influencers to say "no" to SDN with little understanding of whether the risks can be mitigated.

But SDN is so plainly awesome!

It seems somewhat heretical to even doubt the eventuality of software-managed everything -- it's just so obviously The Right Thing to Do. And as long as SDN is a component of network as a service provided by containers, cloud or controller overlay, rank-and-file admins will adopt it because they won't have a choice. Momentum drives real change.

But it's also possible, especially in the networks of small and medium-sized businesses, that management will dig in their heels and block SDN adoption. Perhaps some will feel their business is too unique. Others may resist upsetting budgetary and political fiefdoms. And some may simply feel safer with distributed human administration.

How many other uber, pan-org projects have failed? Why should SDN be different?

Next Steps

Does the networking industry need an SDN reality check?

SDN use cases emerge

Why some network engineers give SDN a thumbs down

This was last published in August 2015

Dig Deeper on Software-defined networking