“DevOps”: a decade of confusion and frustration

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.

Recruiters and companies love the term devOps, and now DevSecOps, because it enables them to keep job descriptions generalized. This way you can be a software developer that is fluent in Python or PHP, but they can also pressure you to do everything from writing proposals to setting up and securing app infrastructure in the cloud (because it's all called devOps now!), that way they can reduce the number of overall jobs for projects and make sure apps have massive gaps in configuration and implementation... It's also the reason why many apps and sites fail regularly, because you can only squeeze so much juice out of a lemon, and less eyes on a project mean testing is often deprioritized and even skipped due to the cost of doing it.

By combining roles and spreading them across multiple disciplines it can also cover bigger salary demands of the most talented developers, but it also drives burnout and toxic work culture.

For example; A traditional development team of 4 people (e.g. 1 front end dev, 1 back-end dev, a System Admin, and a tester) is now cut down to 2 people. 4x 60k salaries now cover 2x $120k salaries for people that do everything under the flag of devOps... The company bills hourly now rather than per employee, but saves money by only having to cover costs like health care for 2 employees now instead of 4... Classic "corporate shell-game" move. :/

The system is broken, and mostly driven by marketing and profit-driven results. Don't fall victim to the hype, get them to fully detail your line of work prior to joining a team despite it being no consolation on what your actual role will involve. :P

For me dev-ops is exemplified by:

1. Everything being scripted, reviewed and in the repo (no ad-hoc actions on prod)

2. Processes are ephemeral (containers)

Everything before that (VMs..) is in the age of the sys-admin.

This person does not seem to have any problems.

Better spend your time with some research on current climate issues.

This was as obvious in 2009 as it is today. And like Agile before it, if you make any negative comment about it you are immediately hit with "you're holding it wrong".