DevOps Engineer is the new SysAdmin

If you don’t do dev… You just did the ops

Dropdown of actual job selection from companies that consider DevOps to be something that operations do

DevOps engineers seem to be the position that causes quite a lot of confusion. Maybe it’s because it’s anti-pattern. Apparently, many companies think they can hire someone and suddenly become DevOps. They want to “change” without actually changing anything! (except to change the title “SysAdmin” to “DevOps Engineer”). 😉

The reality is that DevOps is not a position. It’s not something one person or a team does. This is a cultural transformation on an organizational scale. It is the practice of development and operations engineers who work together throughout the entire life cycle of the software, hopefully in the same team, following the lean and nimble principles that allow them to deliver high-quality software in a stable and sustainable manner. It starts with learning how to work differently and embracing cross-functional teams with openness, transparency, and trust as pillars. If that doesn’t sound like your company, then you might not practice DevOps.

How did this happen?

This is a sad reality for many companies. I saw a job post for DevOps Engineers that explained what is essentially the work of a system administrator with additional responsibility for running CI/CD pipelines or automating infrastructure deployments. Here’s a hint: If you’re applying for a DevOps job and your team isn’t doing Development, it’s not DevOps because DevOps is Dev elopment+ Op eration’s. i.e., “You build it, you run it”. If someone else builds it and you run it, then you’re just doing Operation (or Site Reliability Engineering). There should be no separate development and operations teams in the company that actually practice DevOps, there is only one team that is cross functional and driven by a set of metrics focused on providing value to their customers.

DevOps is about destroying silos, not adding new ones.

Part of this confusion is because many practices came together at once to form the DevOps movement in 2009. Cultural change was at the heart of the movement. You have the influence of Lean Manufacturing, Agile Development and Planning, Continuous Integration and Continuous Delivery, Test Driven Development, Behavior Driven Development, Cloud Native Microservice Architecture, Infrastructure as Code, Immutable Runtimes, etc., and with all these new practices and methodologies come new tools and technologies to support them.

Tools won’t fix your broken culture

When companies create jobs for DevOps Engineers, they mostly want operations people who understand these new tools. Companies don’t understand that tools won’t fix their broken culture. They are actually satisfied with someone managing a pipeline for a developer when it would be much more productive for developers to learn how to set up their own pipeline and manage it. So instead of devs throwing their broken code against the wall into ops, they’re now throwing it at the hapless DevOps Engineer who tries to create a working pipeline from it and then hands over something that works to the ops. Good for devs… good for ops… bad for DevOps Engineers.

If a company wants to adopt DevOps, and they think that the developers will continue to work like them for years, then that company will never become DevOps. Because DevOps requires devs to change the way they work, and ops to change the way they work. The last thing needed is a new team to protect developers from operations while they continue to work in their silos.

Destroy silos

One of the main reasons for adopting a DevOps culture is to break down silos. So, if the company you work for still has silos with hand-offs, (or worse, they’ve created the 3rd silo between development and operations called “DevOps Teams”) they don’t practice DevOps. DevOps forces have a complete responsibility for what they commit, build, test, deploy, maintain, operate, everything! Of course there are different ways to achieve this, but the mantra “you build it, you run it” is the core of DevOps.

Conclusion

The DevOps Engineer position has little in common with the DevOps movement. I think you’ll find that if you change one of these DevOps Engineer positions to System Administrator and read the description, it might still be a perfect fit. Maybe they should find an Automation Engineer. But don’t confuse automation with being DevOps. Automation is part of the DevOps philosophy but only one part. Adopting automation without changing your culture to a DevOps mindset of trust, transparency, and a quick round of feedback, it still just implements automation. I have found that the devops engineer position is almost always a pure Ops position without Dev.

I say this with all due respect to those who hold the post of “DevOps Engineer”. The work you do is very important, and the skills you have are invaluable and sought after, but the company you work for doesn’t practice DevOps if they put you on the DevOps Team. Remember, DevOps is about destroying silos, not creating new ones.

4 comments

  1. After checking out a number of the articles on your web site, I truly appreciate your way of writing a blog. I added it to my bookmark website list and will be checking back in the near future. Please check out my website too and let me know what you think.|

  2. Hello there! This blog post could not be written any better! Going through this post reminds me of my previous roommate! He always kept talking about this. I will forward this post to him. Pretty sure he will have a very good read. Thanks for sharing!|

Leave a comment

Your email address will not be published.