DevOps probably shouldn’t be viewed as a position: Impressions from DevOps Talks Melbourne 2017

*This is a post from 2 months ago that I have reposted in order to centralise my public essays/blogs. I just don’t wish to keep all my social-media-related eggs in the LinkedIn basket.*

Over the 11th and 12th of May I attended DevOps Talks Melbourne1, a small in capacity but big in value conference. This being my first offical professional conference (beside AWS Summit but I’ll be the first to admit that these events could not possibly have been on more opposite ends of the spectrum) I learnt a lot of things, with my impression of the term “DevOps” having gone through the most drastic mutation.

It wouldn’t take much for someone to view DevOps as a role, many places award titles to engineers such as DevOps Engineer, DevOps Manager and other wildcard absuing DevOps-* variations. Articles throw the term around in a mish-mash of ways. And in general, from what I have heard and read, people view DevOps less as an idea or concept, and more of an all-encompassing Übermensch, a person in the company, if you will.

I guess I was also privy to this opinion before attending the conference, and really, it’s understandable, we give people titles based on what they do, and by that, guess what people do by their title, so it’s fair to extrapolate that if someone IS a DevOps, then DevOps is what they do, and what they are is DevOps. So DevOps is a thing you can do, like hammer a nail, or drive a car. “Look Mum, I’m doing the DevOps”.

But if the presenters at the conference, and the supplementary material2 I’ve been making my way through has anything to say about it, it would be that there needs to be a switch in how we understand the idea. DevOps to me is more about the scientific method than anything else, it’s continously checking the results (the M in CAMS2) of your incremental improvements, making sure that little bits of change are isolated so the impact can be viewed in an objective manner. It’s about automating out repetitve tasks, so more time can be spent on higher value activities. It’s about maintaining a careful eye not just on the technical side of things, but also on the human element involved over the lifecycle of a product/project, being able to talk with both technicals and non-technicals at their level. The community has the acronym CAMS as a way of drumming down the most important values of the DevOps movement.

But in saying all this, I guess you could easily just construe these views as “Just stick a tool on it and bingo bongo, we’re DevOps”, but I think the most important thing (to me at least) was the creation of a culture, and ultimately, I feel that’s largely what it all comes down to, if you are involved in DevOps, you’re more of a conductor, ushering people into desirable practices and trying your best to create a conversation around more effective ways of doing things. You could easily slap a new tool in place, but at the end of the day, it won’t solve the problem, and in reality, could very well add to whatever issue you are trying to fix.

I’ll probably be writing a lot more about this, it’s piqued my interest now, but I don’t wanna go overboard with a tl;dr.

Finally, to steal/adapt the footer from the blog of Coda Hale.

I’m just a junior, so keep in mind that I could be wrong, ya know.

PS: Early bird tickets to DevOps Talks Melbourne are now on sale, I’ll be grabbing mine soon, I would recommend you do the same. Links are in the references.

1. http://www.devopstalks.com/

2. https://www.edx.org/course/introduction-devops-transforming-linuxfoundationx-lfs161x

3. http://devopsdictionary.com/wiki/CAMS

4. https://codahale.com/