To Climb the Automation Everest You Need Workflow Sherpas
A couple of months back, Juniper hosted one of our Juniper Technical Advisory Board events where we bring in a bunch of customers and talk about what they need and how we can help them. On Day 1, most of the customer feedback was on network automation. I had a Day 2 speaking slot to talk about SDN.
But a funny thing happened on my way to the base SDN discussion I usually deliver. I opened the session with a few open-ended questions about SDN to assess foundational knowledge and gauge interest. The first comment from the audience was "What does SDN stand for?" Now, you might be like I was and assume that this was an anomaly, but surveying the room of network architects and operators, this gentleman was not alone. Sure, some might have known the acronym, but only a small handful showed any real comfort with the topic.
As I talked, the general sentiment in the room became crystal clear: SDN might be sexy, but what about the less sexy problems that real networks face?
The conversation was jarring to be honest. I have been in the pro-SDN camp since before SDN was cool. Dave Ward (then at Juniper, now at Cisco) had converted me very early on, and I have spent the past two and a half years extolling the virtues of SDN, both internally and externally. But the JTAB event led to an awakening for me and my team.
A couple of days later, Derick Winkworth (@cloudtoad) and I were chatting and he drew the following picture on my whiteboard (doing my best to preserve the actual drawing):
Basically, what Derick said is that "we" (using the term to describe SDN advocates) are on top of a mountain. On the other side is a Valley of Awesomeness with unicorns and faeries. And unless you are on the top of the mountain, you cannot see the valley. But the people we are trying to get to the top of the mountain are not halfway up the mountain like we thought; they are somewhere deep in the forest and cannot even see the mountain. When we talk about the Valley of Awesomeness, they cannot even imagine such a place because where they are is nowhere close.
Now, cute metaphors and goofy pictures aside, Derick's point is actually a good one. With all the talk about SDN, the promises of dynamic networks, the future of application-network collaboration, ephemeral state, you name it... with all of this talk, we have obscured the fact that led to SDN being launched in the first place. Namely, networking is hard. And it shouldn't be.
If the name of the game is workflow automation, there are things we can do to make an immediate and tangible impact today. For most operators, even automation means a pretty wide range of things. For far too many, automation is cobbling together a couple of shell scripts or maybe a Perl script and calling it "automated". Properly constructing workflow tasks in a scalable ad reusable way is often an afterthought.
What many people in the network world need is a workflow sherpa - someone to carry the automation load as they ascend the automation Everest so they can get a peak of the valley on the other side. Talking about the millionth step before having taken the first is premature and not extremely helpful.
Think about it this way: if automation-readiness is a scale from 1 to 10, where 1 is not automated and 10 is full SDN, most people are probably at a 3 or 4. Focusing on what a 10 looks like is fine, but what people need is to get to a 4 or 5. The reason Gartner's Trough of Disillusionment even exists is because with all the hype comes a distancing of the visionaries from the actual problems.
Now, I don't want to give the impression that you don't need visionaries - someone has to know what direction to head. Visionaries are absolutely necessary, but they are not sufficient. And while the role of the visionary is sexy, no one climbs Everest without a team of sherpas.
Along those lines, check out some of Derick's workflow automation examples (go to about the 40-minute mark).He shows a workflow automation script that expands the MAC table outputs on a switch to include the user name and phone extension by pulling the IP address from the SIP endpoint. Game changing? Probably not, but this is an example of the load that the workflow sherpas need to carry.