#SDN Which came first?

Pundits, owing to SDN still being very young and not widely adopted, continue to put forth treatise upon treatise as to why organizations should be falling over themselves to go out and get themselves some SDN. Now. Not tomorrow, today.

One of the compelling reasons to adopt is to address a variety of operational issues that arise from complexity and differentiation in network elements. The way SDN addresses this - as do a variety of other options - is standardization. Note this is standardization with a little "s", not the capital "S" that might imply industry-agreed-upon-and-given-an-RFC standardization.

The claim is simple: organizations have a whole lot of various standalone appliances in their network serving a variety of purposes. Load balancing, firewalls, IDS/IPS, application acceleration, and even identity and access control. All these individual appliances are (generally) from different vendors, each requiring their own management console, their own policy formats, their own.... everything.

The argument goes that if you take all those services and deploy them as services on a (common) network operating system, you'll reduce complexity and all the associated management (operational) overhead. Rainbows will sprout from the network and unicorns will dance merrily from node to node while sprinkling happy dust on your engineers and operators.

Okay, maybe the rainbows and unicorns aren't part of the promise, but the nirvana implied by this consolidation on a standardized (common) network operating system is.

Now, I'm not saying this isn't true. It could be*. You can get standardization (theoretically, at least) from SDN at the upper layers of the stack, but it isn't SDN itself that elevates the data center to a level closer to operational nirvana, it's the standardization on a common platform. SDN is (theoretically) just one path to achieve that standardization.

The Layer 4-7 Landscape

The reason achieving this is more difficult than it sounds is that there are far more functions at layer 4-7 that need to be "standardized". Organizations do, in fact, end up with a hodge-podge of appliances deployed to support all the various layer 4-7 services required. Let me illustrate with a diagram (that is itself incomplete. There are a whole lot of services that go in the "layer 4-7 category"):

the difference

Are organizations struggling with the proliferation of devices at layer 4-7? Absolutely. I've heard stories of folks with 20 or more different vendors operating at layer 4-7 in their network. Not kidding. And every day, every new challenge brings another new solution to the table. Mobility and cloud - not to mention security - are driving the identification of new problems and challenges which in turn drives the proliferation of new solutions that often (though not always) come in the form of a nice, neat box to deploy in the network.

The way in which this proliferation (and its associated overhead) can be effectively addressed is through standardization. That doesn't require SDN, though SDN may be one way in which such standardization is achieved. Standardization - or more apropos - the consolidation of application (that's layer 4-7) network services onto a common platform is what brings that benefit.


* It could be if we ever figure out how to deploy said services in such an architecture without forcing the controller to be part of the data path.