by
Join the DZone community and get the full member experience.
Join For FreeIt’s been a couple heated weeks on the devops front. In part due, again, to the NoOps debacle (see Cockcroft’s post and Allspaw’s reply) and for the other part due to this statement:
[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.)
This was commented on by Philip Hollenback in a blog post on the perception of devops. I totally agree with Philip and would like to echo his closing point:
Basically I want to find a way to embrace more than just "puppet and chef" in devops. [...] Let's not get bogged down on specific technical implementations.
This mindset matters a lot. I will go as far as saying that
this is the only way IT organisations have a chance to truly succeed.
Also, this is especially important for a community that was born out of the intent to unite groups and people for a greater good. We all know it’s hard and there’s an agreement that the original thread where this episode started had some connotation of trollig, however:
- If we want to succeed bridging the gap between groups that frequently have different perceptions and approaches we must get better at mediating and tackling inflaming positions
- Tools are just that, tools. I once came across a company that had some great agile-inspired values among which there was ‘people over tools’.
We need more of that and it needs to be reflected in the ongoing
conversation. The original poster was asking about tools, but ultimately
I think that conversation could have been framed in terms of
communication. Take stuff like monitoring and metrics: you can think
about it as numbers and tools, or you can think about it as information
on which to build a dialog about a system. Perspective matters.
- Business first. Again, setting aside the feelings and experiences we have when it comes to a big ball of mud of bash scripts, is moving to puppet and chef always the right decision? Probably not. Best is always relative. There’s
not best or even better technology, there are only technologies that
work well for the problem at hand at that point in time and maximise ROI.
And let me stress that that does not imply one should ignore design and
be shortsighted, it’s a tough balancing game. We should try to frame
conversations in terms of understanding the other side’s reality and
drivers before making a recommendation so to maximise their benefits.
This is hard to do on a mailing list and maybe not even appropriate, I
respect that, but again, perspective and attitude make the difference.
- There is a fundamental problem with the definition of devops
and I suspect some of the problems we’re seeing won’t go away until
that is settled (if it ever will). There are fundamentally good
reasons why this hasn’t happened, primarily the fact that once you have
a definition, a certification, a job title and so on you’ve potentially
created another silo. It’s also hard to define a culture. I have mixed
feelings myself and certainly it’s a hard (wicked) problem.
To close, I’d like to make an appeal to people to share more about their success stories bridging the gap. I’m sure there are plenty. Maybe because we’re technical and/or maybe because we don’t like to talk about squishy stuff like emotions, the conversation seems to largely focus on tools and processes. There’s a place for both, but right now there’s an imbalance that I think we need to remediate to for the sake of the success of this great community.
Published at DZone with permission of Spike Morelli, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments