Do DevOps Tools Really Exist?

So I was stumbling around the web this morning and I found myself in the LinkedIn DevOps group. Browsing around I came across several discussions on “DevOps” tools. Now a lot of companies and projects out there use the DevOps keyword but not many of them would label themselves a “DevOps Tool”. For good reason too. It doesn’t take much googling to be assured that DevOps, like Agile, is not about tools. DevOps is about principles, methods and practices.

Principles, methods and practices bore the life force out of me so I lazily boil it down to one key concept, collaboration. The cliched image for this is a group of developers and sysadmins standing hand in hand, naked in the woods, singing kumbayah until shit just works. It should also include testers, security specialists and environment and release managers too (sorry architects*, we’re getting stuff done here )

With this in mind let’s get back to the notion of a “DevOps tool”. Reading the threads I see the usual suspects coming up. Puppet, Chef, Capistrano, Jenkins, Monit, Fabric. Now don’t get me wrong, these are all great tools and they all have their place in an agile minded IT shop which professes to “do” DevOps. But are any of these tools truly cross-functional? Can they really promote collaboration across teams. Are testers reviewing Puppet manifests? Do sysadmins typically contribute to Jenkins projects? How many developers are adding management packs to their company’s SCOM implementation?

We love our tools. There is no doubting it. When we specialise we come to love their complexity too though. It gives us power and it makes us feel superior. Have you devs out there never laughed at old school sysadmins trying to code an automation? Have you sysadmins never laughed at a dev fumbling their way around a command line? Whilst the benefits of this specialisation have been understood since Adam Smith profiled the original Pinterest** we still need to acknowledge their impact on collaboration. When developers and sysadmins aren’t talking the same language, when they’re not using the same tools then collaboration suffers. When collaboration suffers then your DevOps initiative suffers too.

So when you next think about what “DevOps tools” are available ask yourself how they support collaboration. There will be exceptions but in most places the DevOps toolset will be enforcing pre-existing silos because the user base for each one is too narrow. I would never suggest dumbing down these tools to ensure broader usage but they shouldn’t be walled off. When the information these tools store is open and available, when everyone can contribute to it then DevOps magic will just start to happen.

Well, that’s what we believe here at ScriptRock, and it’s the principle that we’ve built our platform on. Whether you agree or disagree we’d love your feedback. Hit the “Get Started” link and try it for yourself.

* I was an architect in a former life so it’s totally cool for me to say this ** Featured Pin Factory in the Division of Labour (it was a hot startup, sweeping the 1776 Crunchies)