I’ve been thinking a lot about SDN recently, as you can no doubt tell from the number of blog posts that I’ve been putting out about it. A lot of my thinking is coming from the idea that we need to find better ways to relate SDN to real world objects and processes to help people understand better what the advantages and disadvantages of all the various parts can be.
One example of the apprehension that some feel with SDN occurred to me the other day when I was in a conference center restroom. Despite all the joking about doing the best thinking in a bathroom I found a nice example based on retrofitted old technology. You’ve no doubt seen that many restrooms are starting to install touchless flush sensors on their toilets and urinals. There are a myriad of health and sanitation benefits as well as water cost savings, not to mention saving maintenance costs on the handles of these units.
The part that made me curious during this trip was the complete lack of any buttons on the unit for triggering a manual flush. Most of the touchless toilets and urinals that I’ve seen have some sort of small button used to flush the unit at the behest of the user. While these buttons are probably not used all that often, it is a bit reassuring to know they exist if needed. Imagine my surprise when I found the units in this particular convention center with no button whatsoever. A completely closed system. While I was able to finish my business without further incident, it made me start thinking about these kinds of systems in relation to SDN constructs.
My go-to example for this type of issue used to be an automotive one – the carburetor and the modern fuel injection system. Carburetors are great ways to deliver a fuel/air mixture into an engine. They also offer a multitude of customization options and performance tuning capabilities. They also represent the type of arcane knowledge that’s need to make one work right in the first place. If you misalign a jet or don’t put things back together correctly, you can very easily cause your engine to run improperly or even cause your car not to start. The customization ability exists along with the possibility of causing damage if you aren’t properly trained.
A fuel injection system, on the other hand, is tuned perfectly when it is installed. Once it’s bolted on to the engine, it becomes a cryptic black box that does its job without any further input. In fact, if something does go wrong with the fuel injection system there’s likely no way you’re going to be able to work on it unless you are an S.A.E. mechanic or fuel injector designer. The system does its job without input because of the initial tuning.
How do both of these examples relate to SDN? There are some that say that a properly functioning SDN system will use analysis and inputs to determine the best way to install flows into a device or build overlays in a way to maximize bandwidth to critical systems. It’s a steady state machine just like a fuel injection system or a buttonless toilet. It offers no way for people to provide inputs into the system to influence behavior. You might say that a system of this nature is far fetched and fantastic. Yet we seem to be leveraging a multitude of technologies for the purpose of removing as much input and decision making from the network as we can. Is it that much of a leap to decide that we want to remove external variables totally from the equation? I think that will be a focus on the next wave of SDN once the baselines have been established.
People don’t like steady state black boxes. They like having an override switch or a manual activation button. It reassures them to know that they can have an impact on the system no matter how small. It’s a lot like the crosswalk buttons on street corners. Even if they are programmed to have no effect at all on the light schedule pedestrians feel more comfortable having them around. The average engineer hates having no input into a system. That’s why full network automation is so scary. What happens when things go off the rails?
If you really want to make sure that people feel comfortable with the idea of a fully automated SDN solution, the key is to give them meaningless input. Make a button or a field that lets them think they are having an impact without really taking anything into account to create the best path through the network. Routing protocols show what happens when people think they are smarter than algorithms. Imagine what would happen if that level of interference would happen in a data center. The fix might not be as easy as backing out a static route. In truth, I don’t think the data center world is quite ready for a fully automated SDN solution right now. Maybe once we’ve gotten them used to the idea of buttonless flush toilets, we can introduce the idea of a buttonless data center.