DevopsPerceptions
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.
