InformationWeek Green - Mar. 4, 2013

InformationWeek Green

Software-defined networking is in an enviable position: Everyone is excited about the concept and wants to believe in it. Among networking professionals, expectations are high. But don't make the mistake of looking at SDN as just a new tool to solve yesterday's problems.

Vendors are falling into this trap as they seek to market and monetize SDN before the new-car smell wears off. OpenFlow, because it's a standard, is an exception, but we see SDN-like capabilities baked into a number of proprietary and only partially standards-based systems. Sure, most vendors promise to support OpenFlow in addition to proprietary code, but the temptation is strong to "embrace and extend."

As chief architect of the InteropNet and CEO of a technical design company, I understand that it's normal for IT organizations to come at software-defined networking from the perspective of an engineer: What's broken that can be fixed by the ability to program a network to dynamically change its operating mode or parameters via a programmatic method?

Use SDN to make the current network better, sure. But it's more important to think differently about how SDN will help us design and build the network of the future.

Ahead, Not Back

It's not an easy mindset to break, that tendency to look at new tools as solutions to old problems. We've been beaten down by proprietary feature sets designed for the lowest common denominator. Want to do something out of the ordinary? Sorry. It was a case of: "Here's the network and these are the things it will support. Deal with it." That led CIOs to say: "Sorry, CEO/CMO, but we can't support your project unless we spend [huge sum]. Let's budget for that next year."

No wonder business leaders listened when infrastructure-as-a-service vendors came calling.

SDN can put us back on track to be flexible and open to the requirements of today's business leaders and users -- who are, let's face it, dictating what networking pros need to focus on. The most recent example is consumer technologies, mainly tablets and smartphones. Tomorrow it'll be an explosion of new applications, or something else, and I have no doubt SDN can be part of the solution. Rather than respond to requests for a new feature by saying "not without lots of time and money," SDN can help us say: "Yes, we can do that. We just need a couple of days to tune the infrastructure."

For now, SDN is confined to large data centers. The sweet spot for the Googles and Amazons of the world is the prospect that an app can communicate with the underlying infrastructure to enhance performance or solve problems based on specific parameters. Your average enterprise, however, doesn't have this expertise in house yet. This is the biggest challenge and greatest opportunity for SDN vendors. The hardware is available and at a price in line with market expectations. Now help us learn.

The big challenge for IT teams? Think of SDN not in terms of perpetuating the status quo but as a tool to transform how the network supports the business.