News Stay informed about the latest enterprise technology news and product updates.

To push past SDN hype, it'll take innovation by the networking 99%

The hype around SDN will be short-lived, then fade, but network admins must be willing to learn how to make SDN work after vendors have moved on.

Network pros are growing impatient with SDN hype. They're increasingly critical of the lack of real-world technology, as well as of standards bodies that are being driven by vendors with deep pockets.

But as network engineers, we must take the long view of SDN. We have to ask ourselves what we hope to achieve with SDN in three, five or 10 years, then figure out how to make that happen -- even if the vendors mine their profits and then abandon further innovation.

When their short-term goals are achieved, many vendors will pack up their heavy marketing artillery and move on. We implementers must be the equivalent of peacekeepers, willing to stay on the ground in white trucks marked 'SDN' for at least a decade.

What happens when the networking 1% make all the SDN decisions?

As with most market cycles, major vendors have evaluated the SDN opportunity, and once they've mined its bulk, they will curtail further major investment. The 80-20 rule is never more evident than in next-big-thing technology. Vendors tend to capture 80% of the revenue with 20% of the potential investment, and call it a job well done. But for SDN that's not acceptable. The other 80% of its development must continue to change the way we think about networks. We can't pull our fingers out of the command-line interface (CLI) until there's proven, rich functionality that we are willing to bet our businesses and careers on.

Yet practitioners are largely shut out of the standards game. Cisco, IBM, HP and Citrix can spend $500K to put more than 20 people on OpenDaylight. We can hope these OpenDaylight members are reading the blogs of some of the brightest minds in networking, or keeping up with the message boards that host engineers, but they're under no obligation to do so. What's more, they have their own agendas that often run counter to admins' interests. So, at least for the short term, practitioners are often stuck on the sidelines watching the networking 1% set the direction for SDN.

SDN haves and have-nots

As all this takes shape, the question becomes: Will SDN will become fragmented between the haves and the have-nots? The haves are cloud providers and very large data center operators that built out proprietary virtualized networking systems years ago. Amazon, Rackspace, Google and Facebook already rely on software-driven architecture. For them, SDN simply standardizes established best practices and decreases costs as vendors provide more built-in support. Indeed, it's likely that accelerating adoption of Open Compute and its extension into networking is a significant motivation for established vendors' SDN investments.

Meanwhile, the have-nots are any organization that's unable to wield specific, late-model, single-vendor hardware stacks, or those that don't have deep technical expertise. Sure, they'll be able to take advantage of some benefits of virtualized networking, but they'll use only the same depth of SDN features as they use in their server virtualization stacks today. Consolidating servers through virtualization is easy and produces worthwhile ROI. But to truly make vSphere sing with dynamic provisioning, burst scaling, and so forth, organizations must pass a minimum bar of team expertise and executive zeal. It's not much help if the 99% end up with yet another GUI providing a data-center-targeted subset of what we need to manage the whole network.

After the SDN hype, admins need training, open minds, time to mess up

When their short-term goals are achieved, many vendors will pack up their heavy marketing artillery and move on. We implementers must be the equivalent of peacekeepers, willing to stay on the ground in white trucks marked "SDN" for at least a decade. We'll have to sort out local squabbles and slowly create coexistence, cohesion and interoperability. Fortunately, network administrators are IT's nation builders, evolving tools and methods over time.

More on the
SDN market

Is SDN washing the new cloud washing?

Five SDN problems

It'll take a channel to drive SDN sales

Specifically, we'll need to achieve three goals. First, even crotchety admins must remain open-minded, and try to accept that using software to define networks is the right path. Second, we'll need practical education. When will Cisco offer a CCSDNA? SDN can't just be an intriguing resume extension; it needs to be another universally understood technical qualification. Third, we'll need time -- time to experiment, time to play, time to make mistakes. Our years of accumulated CLI magic didn't appear overnight: It was hard-won in the trenches.

Employers will need to protect R&D project time for admins to create and tear down SDN infrastructure in the lab. They must be willing to let us occasionally blow up services as we roll out SDN tests on low-criticality systems. Admins won't be able to settle for assurance from their VPs that vendor X says, "Just install and go" -- no matter how great the pitch was to the CIO. We are the grid. We keep the lights on. If we take the long view and double-down after the hype, SDN may yet change the world.

About the author:
Patrick Hubbard is a head geek and senior technical product marketing manager at SolarWinds. With 20 years of technical expertise and IT customer perspective, his networking management experience includes work with campuses, data centers, storage networks, VoIP and virtualization with a focus on application and service delivery in both Fortune 500 companies and startups in high tech, transportation, financial services and telecom industries. He can be reached at

Dig Deeper on Software-defined networking

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Who will lead SDN innovation?
Networking vendors have a vested interest in tying you to their hardware. If you cannot substitute one device for another and you are tied a vendor's implementation, you are not doing SDN.