I know that everybody say this, but my experience in real world tells me differently. DevOps is a skill, beside being anything else.

Good DevOps engineers are above everything else good developers. Those kind of developers like to control every aspect of the final product so then they enter system administration, networking, deployments, metrics etc.

On the other hand there is DevOps culture and teams and that is something else and can be reasoned about separately.

Exactly. A devops team has a spectrum of people. Some who only do dev, some who only do ops, with plenty who can do both occupying the space in the middle. There is room on a devops team for people who can't code, and there is room for people who can't be trusted to sudo to root.

Not every person on the devops team needs to be a perfect 50/50 split of dev and ops.

And people work on those teams. We are talking about the expected abilities of such individuals. How do you assess these abilities? What is expected?

The whole point is to make your team heterogeneous*, so in terms of skills you need to staff for all your needs.

"We'll use python on GCP with PostgreSQL as a backing database"

Well, then you need an expert in GCP, Python and postgresql. This can be as many people as it takes to have those skills covered.

As for responsibility, well, that goes for where your skill is. If you're the resident postgresql expert then you're expected to be responsible for supporting people with it.

It's likely you'll need to worry about patching the OS and stuff like that, but I don't think you need a dedicated person to be responsible. The point of DevOps is mostly to bring down the silo'ing, not to eliminate a particular role.

But it certainly appears employers are salivating over the idea of hiring less specialists, or simply rebranding sysadmin to "devops".

> The whole point is homogeny,

I'd rather say the point is the opposite; devops teams are (even moreso than agile dev teams) heterogeneous (or “cross-functional” or “multi-disciplinary”).

There's basically a continuum where assembly line analysis / dev / test in separate teams (and security, operations are separate higher level organizations with the technical area, and business is separate from technology) is one extreme, then agile dev teams unifying the analysis/dev/test functions, then devops, then devsecops, then maybe the other extreme is some thing that goes beyond devsecops where also domain expertise (and not just the system analysis skills that interface with domain experts to elicit requirements) are an organic part of the team.

But each step along the line does increase the expected range of skills of an individual team member, because you need also to avoid any team member being a single point of failure and you have to keep teams in manageable sizes (e.g., 5-9).

> The whole point is homogeny,

Whups, I used a very wrong word here, I meant to use the word "heterogeneous". My apologies :S

Based on the role you expect them to do in the team?

Hire the software engineers with an appropriate interview process covering development practices and coding.

Hire the system administrators with similarly appropriate interviews.

Hire the database administrator with their own appropriate interview.

Is this that hard?

>DevOps are teams Despite having worked on a DevOps team in the past, I would disagree, in favor of "DevOps are companies". A DevOps team is just another silo, while the DevOps approach should be implemented at a company level to be most effective.