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.
Black Boxes
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?
Tom’s Take
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.
Tom, I really like your analogy. I like to challenge you though. I get the feeling that you interchange the terms automation and SDN, like they are equal. In my opinion they are two completely different things. You can have a manual managed SDN solution, just like you can have a fully automated legacy network.
I do agree that current engineering is very much afraid of losing the manual controls, but to stay with your analogy: how many engineers do chip-tuning in where they programmatically influence the fuel injection system?
Great article as always Tom.
We are not ready to turn things over to a machine, at least not our network, yet. Even though the great majority of network problems I have encountered were usually due to human error, so it has to make you think – are we doing more good by controlling thins manually – or actually making it worse?
I do see this as a step in the direction of giving control of everything to a computer which reminds me of a famous quote.
“The Skynet Funding Bill is passed. The system goes on-line August 4th, 1997. Human decisions are removed from strategic defense. Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. In a panic, they try to pull the plug.”
So yes it can become scary… 😉
To me it is about loss of visibility and management. These issues have yet to be fully addressed by any of the SDN based approaches out there. No network engineer worth their salt is going to let a dc guy freely provision and allocate network resources without some sort of control point. Because we all know who is going to get stuck fixing it when it breaks and it will break.
Fuel injectors and hands-free auto-flush toilets are not the best example of human-free automation. The following link gives a better example of a fully automated complex system that lacked human override — http://goo.gl/gYo2P. Data centers that are intended to serve many purposes and be useful for many years are more like the latter.
Pingback: End Of The CLI? Or Just The Start? | The Networking Nerd