Abstracting vs Ignoring
There’s a running meme in networking that has caught a lot of momentum with SDN: abstraction. Just about every vendor these days has bold ambitions to abstract out the complexity. There are APIs, abstraction layers, and architectural shims that all aim to hide complexity from the user. But what does that really mean?
The primary goal of abstraction is to break something down into its most essential elements. You then expose only those parts that require end-user participation (think: configuration knobs, for example). Ideally, a small set of relatively well-understood parameters can then move the mass of hulking machinery underneath. The complexity? It is hidden, cleverly abstracted away from the user.
This leads to an interesting question: which bits need to be exposed to the end user?
The question seems innocuous enough. But the answer depends an awful lot on your context.
Networking has long been a management-through-precision proposition. That is to say that network behavior is determined by correctly setting a bunch of configuration knobs. The problem is at its absolute most horrible when specifying edge policy. So acute is our collective need for control that we have developed entire businesses around merely demonstrating proficiency in the knobs themselves.
The subtle point about abstraction is that by reducing networking to only the most critical characteristics, you are actually taking away some of the power from a user base that has defined their careersby their knowledge of said details. On the other extreme, you have an entire class of companies for whom the network is just not that interesting. At the limit, these companies simply want the network to work. That this currently requires an army of specialists with total command over thousands of widgets is more necessary evil than desired outcome.
So what do we do?
In some ways, we need to fight our own instincts. Our need for absolute control is our own doing. We have taken a largely incremental approach to networking for more than a couple of decades now. We have layered functionality on top of functionality, using configuration to incrementally enable each piece. The thought of things working across the whole of the network is a scary proposition, so we have grown accustomed to piecemeal deployments. And change has become so difficult that you don’t dare do anything unless you absolutely have to.
But despite all of this, where are we headed now?
We want to code our way out of the problem. We want to add another complex system on top of an already complex—and crumbling—system. Consider that SDN is largely an organic reaction to the failure of vendors to make networks that are manageable. Building another management layer on top of the existing failed infrastructure might hide the complexity, but it doesn’t remove the source of the underlying infrastructure rot. Without cutting away that rot, we are really just punting the problem into the future.
None of this is meant to suggest that APIs and programmability are not important. For a certain class of user, they are extremely powerful. But not every user has or event wants the kind of sophistication that goes with this type of approach. And fewer still have a solid enough foundation from which to build.
How do I know? We celebrate programmability while swapping stories of companies relying on screen scraping. How is that latter class of networking professionals going to make the leap?
The answer is actually simple: they won’t.
This creates an interesting market dynamic. The number of companies who are actively pushing the envelope is relatively small. Sure, there are lots of people who are constantly evaluating new technologies, but if you measure actual deployments, the business tilts heavily to the less sexy, less risky networks of yesteryear. For every SDN trial that nets a couple of devices in some deal and generates a snazzy press release, there is a pile of uncontested deals that get closed with the incumbent vendors.
Why? Because things barely work the way they are, and adding more capability on top of existing stuff isn’t actually the need for most people.
There is an enormous opportunity for companies that provide a solution to the underlying infrastructure rot. The billions of dollars spent on networks that users wish they could just ignore are mostly in play. The vendors pursuing those dollars need to make sure they keep their eye on the ball. The shiny object that is abstraction and programmability will undoubtedly be important, but pursuing that at the expense of fixing the underlying network is chasing an opportunity that might very well forever be just on the horizon. Over time, the obvious end game here is that both things needs to happen. Abstraction and underlying correction are both required.
While it might be the CTOs and CIOs at the largest enterprises and carriers that drive overarching requirements, the middle and lower tiers of the market consume an awful lot. Interestingly enough, that business is somehow lost in all the noise. To make a difference here, networking doesn’t need to be more abstract; it just needs to be a whole lot more instinctive.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)