Simplify. We all hear it all the time. We hear how this tool or that technology will simplify. In networking, we hear how controllers, protocols, APIs, and virtualization layers will all simplify. Remove a keystroke here. Maybe automate something there. All in the name of simplification. But it might be that our very approach to simplification needs to be simplified.
The most well-known example of simplification being successful has to be Apple’s foray into consumer electronics. The iPod disrupted more than just the handheld music industry. En route to making the Walkman a great tool for making us all feel old, Apple redesigned how we interact with devices, influencing several product generations and an entire human generation.
But what exactly did Apple do?
Apple wasn’t the most fully-featured MP3 player on the market. And it wasn’t that they enjoyed some first-mover advantage in cornering the market. They didn’t even benefit from their content side until later. What the iPod did was much more foundational than any of that. Put simply, the iPod represents Apple’s attempt to ween us off all the functionality that had gotten in the way of a truly great experience.
The iPod effectively reduced the user experience to only those things that were absolutely essential. And in doing so, they presented a user interface that was at once simple and intuitive.
Apple correctly identified that the most important things people needed to do were: play/stop, fast forward/reverse, and search, all in a form factor that was smaller and more mobile. They made the iPod as complex as it needed to be and no more.
What the networking world could learn
The networking world could learn a lot from this exercise. And I am talking about way more than slick UIs that make managing the beast a bit easier.
As a group, we need to reduce networking to its most basic functions. It’s not the capabilities that we actually crave. How could we? The average device in production is using less than 5% of its available capabilities. Interestingly enough, the other 95% of features that go largely unused and likely unnoticed do contribute to the overall cost in networking. Developing the software that drives the network requires extensive development and testing, and every esoteric feature adds just that many more combinations of features that have to be tested (or released untested). With each test, effort, and with each effort, cost. We are all victims of our inability to reduce the superset of things our devices currently do.
If we took an Apple-esque approach to networking, we might find ourselves in a different place. So we ought to ask ourselves: what is the networking equivalent of play, fast forward, and search?
What does the network really do?
Before we overthink the answer, consider the question: what does the network really do? Fundamentally, networking is about two things: bringing things together, and keeping things apart.
At its most basic, the network is about connecting things. We want this thing to talk to that thing. We want this segment of the network to be within the same domain as that segment. We want this set of devices to behave as if they are co-located with that set of devices. So much of what we do is about enabling this type of communication or grouping.
By the way, this is not all just a configuration thing. When we are really trying to optimize performance, we do things like put stuff in the same physical rack so that the things we want to be together are physically close as well. A good example of this is rack awareness in Big Data applications.
On the other side, we work very hard to keep things apart. We employ security and edge policy constructs aimed precisely to do this. We might want to isolate broadcast domains, or keep routes from leaking from our internal networks into our external networks. A rich set of policies have evolved to get very fine-grained control over how we keep things apart.
Everything we do more or less fits into these buckets.
The key to simplifying the network isn’t in putting a layer over the top of a complex landscape of behavior specifications. That just masks the complexity, exposing it in different ways to the user. Doing this makes management simpler but it does nothing to really simplify networking. All the cost (actual expense but also the unreasonable frailty that exists in most networks) stays in the system. Behind the abstraction, people still have to build, test, and support a diverse set of functionality.
Collectively, we sort of understand this implicitly. This is why every few years a new crop of purpose-built solutions comes to market. The idea is that by focusing on a narrower set of use cases, we can start over clean, remove all the complexity and be happy. Fundamentally, this is what Arista did.
The challenge here is that though we start clean, we grow along the same overall trajectory that we always do. Over time, we reintroduce the complexity and hence the cost.
Breaking the cycle
To break the cycle, we need to actually simplify networking. We need to reduce networks to the equivalent of the iPod wheel. Our wheel might have a few more buttons and options because the task we are charged with is fundamentally more complex. But we ought not concede before we start that all the complexity that is there has to be there. The hard work (and the reason no one did it before Apple) is in having the confidence to go to market with something that just works better.
But if you do this, there is an entire market of opportunity waiting. You have to wonder if this market will absolutely jump at the chance to simplify given all they have ever been exposed to is complicating solutions.
[Today’s fun fact: Peanuts are used in the manufacture of dynamite. This is why people with nut allergies should never get blown up by dynamite.]
The post Simplifying network simplification appeared first on Plexxi.
