Trusted Contributor , Trusted Contributor Trusted Contributor
To Climb the Automation Everest You Need Workflow Sherpas
Nov 6, 2012

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.

Nov 6, 2012

I still think you're too optimistic Smiley Happy  This is why, to me, SDN is a fad that will burn out.  Most aren't willing/able to do the heavy lifting.  True SDN requires a tight integration between software developers and network engineers.  At most large networks this is impossible and most attempted projects will be bloated failures.  Those sherpas are hard to find and in most organizations will be hampered by politics.  And I say this as someone who works on a network that has been doing something like SDN for over a decade.   Really doing SDN requires a combination of agility and resources.  Most networks have one or the other but very few have both.


Many engineers like the promise of SDN, but they don't realize the investment in tooling that it's going to take to make that happen.  That being said, I do think the focus on SDN is going to bear fruit for those that are willing to work on it.  I just don't think it's going to turn out to be the revolution that is being evangilized.

Nov 6, 2012
Trusted Contributor



I agree with the sentiment here. And I totally agree that workflow sherpas are hard to find. The task of finding them is made more difficult by the fact that people often don't know what they are looking for, and it is even harder to know where to look. Whatever your personal view on certifications, they do at least make it easier to sift through names and resumes, but how do you even find someone who knows how to build proper workflow? The skill is different (and arguably unrelated) to network skills, so the normal sorts of hiring practices might not easily apply.


Ultimately, though, I think we actually agree. And I do think there is tremendous value in anyone (vendors, partners, customers, whoever) either providing or at least giving tools to workflow sherpas.


As an aside, I am of a different mind on the future of SDN. I believe we won't be talking about it in 5 years, but not because it burned out. I think most of what SDN does is automate workflows (even dynamic networking using ephemeral state is just workflow on steroids). I believe this trend is just the natural evolution of networking, and the SDN moniker will eventually drop. It is useful now as a name to frame the discussion in articles, conversations, and blogs.

Nov 6, 2012

@scott ,


SDN is just a name but the networking world has been evolving around software for many years . Now that hardware is essentially commoditized , services provider's needs to manage virtualization (software).  Everything in the IT sector is a  "FAD" and that's because something new is constantly introduced  to enhance or replace.   Companies like Google require such a solution to manage their infrastructures reduce complexity ...etc.   Derrick touches on workflow automation and I think we're headed in that direction ..and by the way (Derrick ) Python not Perl.  Perl becomes unmanageable after a 100 lines of code ... ha ha !!!

Nov 7, 2012
Trusted Contributor



Agree with Python over Perl. Where do you stand on Python and Ruby? And do you have a preference when you look at things like Puppet or Chef? Trying to get a feel for how you might recommend getting people from a 3 or 4 or 5 to 4 or 5 or 6.

Nov 30, 2012
Great post Michael, As I understand juniper presents SDN capability in 3 ways (JDN): 1) Network Prgramming 2) Openflow 3) Network Automation And there is huge potential with in these domain for apps, solution and services. Would it be fair to call that without Network Automation their will not be any SDN ?
Dec 14, 2012
Distinguished Expert

I loved the video and explainations contained within it. On a practical level I am wondering - the scripts that Derick created and demo'd at the field day. Are they available for download? They really show off a lot of concepts and would be a great jumping off point for those of us struggling with getting our arms around the whole "automation thing"


Kevin Barker
Juniper Networks Certified Instructor
Juniper Networks Ambassador

Juniper Elite Reseller
J-Partner Service Specialist - Implementation