[bump64]

Interesting points but I would like to add my takeout at how I see Devops and how we use Devops engineers in our organization. My previous boss came up with the definition that most closely describes Devops for me and it is the following: Devops are set of practices that increase the team velocity. And in fact Devops engineers wear many hats. The team needs to get faster their code from developer workstations to production - a Devops engineer could help set up ci/cd pipeline. We need more quality checks and gates before releasing to production - a Devops engineer could help. We need the service to handle spikes in traffic, database backups and failover operations - a Devops engineer could help. We need our infrastructure to be scripted as code, automated, immutable and easy to replicate - a Devops engineer job. Developers have a hard time localizing an issue in production - again Devops engineer could help setting up better logging and monitoring. Also it is not a job in isolation. Devops engineers work closely with the team to transfer knowledge about the tools they built and also observe what is blocking the devs from doing their job in terms of tooling. It seems like asking a lot from a single person in that role but for small teams people often do various tasks by themselves. In bigger organizations people could specialize in different roles like release engineers and SRE but I do believe that there is always a need for someone to be in the Devops role to keep track of the bigger picture and bridge the gaps between devs and operations.

[peakaboo]

It's a bit ironic that devops were supposed to make the teams faster but in practice, teams end up troubleshooting why stuff is not working most of the time.

Any team I've been part of has a mile long list of technical problems they are trying to solve, caused by the complexity of the tech stack.

I think a lot of tech workers are not looking for the simplest way to do something. Because what's the fun in that.