Meet the New Software-Defined Network. Almost the Same as the Old Network.

Occasionally when I wake up, I have some utterly obscure question percolating in my brain. Once, it was about the color of the original, undomesticated carrots (white and purple, it turns out–like their cousins the turnip and the parsnip). I have to go look it up so I can go on about my day without further mental interference, which is why I can tell you, for example, that there is an online Carrot Museum that will tell you everything you want to know about carrots. Also, in Afghanistan they make a fermented beverage from wild carrots. (Thanks, brain!)

Today, I simply had to know what “palimpsest” means. Here’s what it means:

A palimpsest (/ˈpælɪmpsɛst/) is a manuscript page, either from a scroll or a book, from which the text has been either scraped or washed off so that the page can be reused, for another document.[1] …In colloquial usage, the term palimpsest is also used in architecture, archaeology, and geomorphology, to denote an object made or worked upon for one purpose and later reused for another, for example a monumental brass the reverse blank side of which has been re-engraved. [Wikipedia]

SDN is an excellent example of a palimpsest. Let’s take the SDN origin story as gospel: why, indeed, shouldn’t you be able to program a switch the way you can a non-purpose-built computing platform? The short answer is because the networking industry, and the devices it continues to produce and sell, evolved in a certain way, and the world is filled with such devices and vast numbers of people trained to interact with them via communication protocols vs higher-level constructs.

So now we’re elaborating an assortment of higher-level constructs under the common banner of SDN. This does not, however, eliminate existing network concepts, protocols–or the actual networks themselves. We are using all of these things as the foundations upon which software-defined networks will be operated, much as the “Troy” excavated (with dynamite!) by Heinrich Schliemann was, in fact, as many as nine different cities, each of which built upon the decaying foundations of the previous one. And why not? It all works moderately well, and we have lots of people who know how to make it work.

The thing about “adopting” SDN is that it’s a little bit of new technology, but a lot of mindset and process shifts. This, I think, is why SDN is starting to enter a winter of discontent (or if you’re more of a Gartnerian than a Shakespearean–a trough of disillusionment). Networking salespeople and users alike are trained to buy/sell boxes that you plug in and that largely ends the transaction until the support contract comes up for renewal or there’s an opportunity to add in more boxes. SDN controllers today, by contrast, are all at the some-assembly-required stage of evolution. And if your SDN use case is BetterFasterCheaper manageability, it’s very reasonable to question why you should go through a whole bunch of new gymnastics moves to do more or less what you’re already doing in a different way.

It would be a mistake, though, to imagine that the current state of affairs is the de-facto nature of SDN. As controllers mature, they will of course become more plug-and-play. Now that the industry has begun to consolidate around a few leading platforms, we will start to see more packaged SDN applications to run on said controllers. Meanwhile, the bleeding-edge organizations moving towards active deployments now are investing heavily in training NetDevs to build their own applications for proprietary use cases. At Open Networking Summit this spring, and in subsequent media interviews, AT&T indicated that they’re putting tens of thousands of network engineers through specialized coding classes. Some portion of those engineers will eventually go on to jobs at other companies, spreading their new expertise into new soil.

And as I wrote in 2013,

…Today’s discrete controllers will wind up going one of two ways:

  • Down, coupled ever more tightly into existing network operating systems, until eventually they will simply be part of OSes with better northbound APIs than before. This will be especially true of “house” controllers from existing networking vendors.
  • Up, as platforms for emerging ecosystems of network applications. There’s nothing to prevent house controllers from moving in this direction, and for major vendors to develop their own developer ecosystems (well, nothing but mindset and institutional support for such)…

There are those, in fact, who expect that controllers will eventually be packaged with applications such that the (micro)controllers are transparent to the user, as opposed to an independent piece of software to be set up and then integrated with a parade of disparate applications. This scenario will necessitate a truly de facto industry controller platform (we’re far from that yet…) as well as a standardized architecture for peer-to-peer controller communications, and mechanisms for defining order of precedence for operations stemming from different applications.

None of this, however, will change what lies beneath in the foreseeable future. We’ll still have some mix of physical and virtual forwarding devices, managed via some set of protocols–some older, some derivations or extensions of existing ones, some genuinely new ones–because SDN doesn’t necessarily change anything about forwarding architecture, and because of refresh cycles and human operator inertia. It will still be valuable for quite some time to understand how those protocols operate on the devices, even as the preferred method for doing so shifts with controller advances and the general state of administrator skillsets. It’s entirely conceivable that 15-20 years down the road, the idea of monkeying around with networking protocols themselves will seem as arcane to most as being fluent in the inner workings of the systems bus in your PC. But we’ve got a long way to go as an industry before that state of affairs appears on the horizon, and most of that shift will come well after we have some semblance of controller maturity and an SDN application ecosystem in place.

Meanwhile, I’ll apparently be mulling over things like the origins of carrots. Stupid brain.

Languid Conversations Among the Enlightened

I’ve come to the conclusion that IT people are always endangered. Their demise is perennially imminent, and it’s always because they’re simply too stuck in their ways, and too stupid and/or lazy to let go of the tried and true, and embrace the virtues of cross-disciplinary collaboration and training.

Here’s an example the relatively traditional version, in which a vendor tells its own core audience that they’re doomed if they don’t buy the latest thing from said vendor. In fact, we’ve got two FUD vectors conflated in this particular sample:

1)      Automation is going to take away your job (even though “our customers are telling us they need automation”).

2)      SDN is going to eliminate everything about how networks are currently operated and force anyone who wants to touch a network to become a programmer.

There’s a particularly tedious corollary to the threat of new technologies, one which comes up in virtually every discussion about emerging technologies.

Continue reading