Devops Perceptions
Last week there was a bit of a dustup on the devops mailing list when Miles Fidelman asked about tools for managing shell scripts. This turned in to a lengthy and often heated email exchange which left me wondering about how devops is perceived by the outside world.
Mies didn’t feel like he got a good answer on the devops list so eventually he asked again on the LOPSA tech mailing list. At the end of that discussion someone asked what the devops list actually was. Miles had this explanation:
[The devops list is] mostly folks who are users, developers, and fans of chef, puppet,
similar tools. A few folks have a broader sense of operations. (Call
me sensitive, but when I queried about management of shell scripts, I
got jumped on by rabid chef and puppet users.)
Well. That certainly doesn’t seem to line up with John Willis’ What Devops Means To Me. It also doesn’t match with my thoughts on devops. What’s going on here?
The bit that particularly bothers me is rabid chef and puppet users. I had to take a step back and ponder this: is that really how devops is perceived by outsiders? If so, that’s no good.
I believe that devops is about the squishy stuff first and the technical details second. That is to say, devops is about Culture and Sharing above all. If you aren’t working in a friendly and productive environment, you just aren’t going to be effective (no matter how many dashboards you have).
After culture and sharing come Automation and Metrics. These are also critical parts of the devops philosophy, don’t get me wrong. You have to automate the work you do, and you have to measure your environment. You can’t make any objective decisions if your environment is uncontrolled and you don’t know how your systems are really performing.
So in this case we have someone who asked a question about managing shell scripts, and his perception was the responses was basically “go use puppet or chef”. Note the use of the word ‘rabid’ - Miles really doesn’t understand why the people on the devops list can’t answer his specific question.
Part of me feels bad for Miles. Here comes this regular guy asking questions about managing his infrastructure, and he just gets a stock response of “use these other tools instead”. That quickly leads to frustration on both sides of the exchange. On the other hand, I’m definitely not saying Miles is blameless - he is pretty determined to stick to his original plan to manage his shell scripts in the face of much counterargument. Many of Miles’ responses come off as borderline trolling. I also personally don’t like the shell script approach as I don’t think it scales well.
I’m not sure if this whole thing could have come out better. Maybe Miles was just asking the wrong question on the wrong mailing list, and there’s no way he would ever get a satisfying answer. Still, he was left with the impression that devops is a ‘bunch of rabid puppet and chef users’. That sucks. For one thing, I believe in devops and I’m not a puppet or chef user. I think those are useful tools that have a (very large) place in this discussion. Still, they aren’t the whole answer. More importantly, they also aren’t the thing I want people to focus on when they think about devops.
Basically I want to find a way to embrace more than just “puppet and chef” in devops. There should be a place for people who want to manage large collections of shell scripts. Let’s not get bogged down on specific technical implementations.
tl;dr: For Devops to succeed we must focus on squishy stuff first, technical details second.
update: sorry I got the gentleman’s name wrong, it’s Miles - not Mike.
Comments
I must confess this line: "A few folks have a broader sense of operations" galls me. I thought, whilst the conversation could have gone better, a lot of his attitude was a) borderline trolling and b) insulting and "My Ops is bigger than your Ops". I suspect some of the conversation would have gone better if he hadn't taken that attitude.
Amen. These tool religious wars are KILLING the impression people get of DevOps outside our tiny community -- in the broad field of IT out there.
In classical antiquity, the Greeks understood that 'squishy' rhetoric (appealing—sometimes using falllacy—first to the emotions) is paramount then comes logic (the technical details) so plus ca change, as the Frogs say.
The devops "community's" biggest problem is trying to do too many things simultaneously, scattered focus.
Philip, I am sure many others share your sentiments about the hardline attitude a "regular guy" might face when asking questions about tools and alternatives.
The spirit of DevOps is meant to be about breaking down walls between silos and see an end-to-end workflow. There is no one size fits all and fundamentally organizations must discover their own improvement strategy and implement it using the skills and assets on hand.
Thanks for taking the time to write this post.
I guess some of this "hardline attitude" is based on long and painful experience. Some solutions scale and some don't. IMHO "managing shell scripts" is an interim solution pretty much every time. As an alternative I don't care what tool you use: CFE, Puppet, Chef, Glu, insertnameoflatesterlanghaskellscalalua tool here. But use a tool/framework that will scale with you and make life better for your Dev and Ops. I care deeply that Dev and Ops people don't go slowly (or quickly) mad because they are overwhelmed, over-worked and unhappy. Because I've been there, it's not fun and I never want to be there again.
That being said we need to better at articulating that point without getting frustrated about it (I found elements of that conversation highly annoying too (see other comment)).
Agreed. I was reading a Reddit thread about this yesterday (http://www.reddit.com/r/sys... and saw the same kind of BS on both sides. There's a perception from within the DevOps community that everyone else must be doing it wrong (as in, why the hell are you heathens racking and stacking machines, you guys don't even automate), and from the outside, it's tool thumping (new and shiny, using the tool even if it doesn't make sense.) I'm guilty of the new and shiny approach myself. :p
But yeah -- I've seen the "DevOps" thing done right, and it's never ever about tools. And it's actually a really awesome thing to behold - but we need to reorient ourselves and see that it's *never* about tools.
Does it really surprise you that someone who uttered the following in the lopsa thread has distorted perceptions?
"By and large, for most mature software that we install, I've found that
the upstream tarballs, install instructions, and makefiles "just work."
Editing a config file is simple, and often automatic. Binary packages
are more of a crapshoot."
From my point of view an idiot asked a technical question, got a technical answer, and complained it wasn't the answer he wanted while disparaging 500 odd people who have vastly more experience at scale than this yutz who can't make his OS's package management system work.
Also his name is Miles
Yeah I totally agree and I tried to call that out in my blog post as well.
Thanks I fixed the name, sorry about that.
I agree his approach was kind of combative. However I also think it's important for the rest of us on the devops mailing list and in the community in general strive towards being more open and understanding in situations like this. I hate to see devops getting a bad name as a closed community that doesn't welcome (or at least tolerate) outside opinions.
Oh, I was wondering if he was Mies or Miles ...