I'm glad I'm not the only one who thinks like this. Every time I read someone referring to, "a DevOps," I wonder what they think they're referring to. No one person is going to be everything you need for effective development and operations combined outside of small, extremely focused scope. DevOps is about avoiding the, "Just throw it over the wall," mentality, not making one person handle the whole thing.
>DevOps is about avoiding the, "Just throw it over the wall," mentality, not making one person handle the whole thing.
this are why it's now part of my interview process when I'm interviewing for a new role "how does your company/team define DevOps?" and I listen very closely for things that sound like 'over the wall-Ops'. Admittedly having the fortune at this point in life to be quite judicious about the answers given.
Ostensibly, if I'm applying for a 'DevOps' role, I shouldn't have to do this if the job description is written well enough, yet even then this has become a learned behavior even when coming across the rare well-articulated job req.
While I largely agree with that, I think it’s arguable that there are a set of technologies that enable that style of working, and that you can call an engineer that specializing in supporting those tools a devops engineer, and a team that supports them a devops team.
Having devops teams and engineers isn’t the same as practicing devops, but once you scale up your org, you’re going to end up with them, anyway.
For example, someone who is good with ci/cd pipelines, infra as code and just generally in automation and observability, as opposed to someone who is strong with linux internals or JavaScript
You can tear down silos all you want, but everybody can’t know everything and people will always specialize.
There's a big difference between people specializing and teams specializing. In every organization I've seen, when you take all of the individual specialists with the same skillset, put them on a team consisting of them (and only them), it ends up being an organizational disaster.
The organizational question is whether the ops folks are (physically/organizationally) colocated with developers on dev teams, or colocated with themselves on an overarching ops team.
