[aprdm]

This is a great post but I want to say that I feel there's space for both. IMO a DevOps Engineer would sit between the sysadmin/network folks and the developers who wants to be users of a system.

In my current gig we've moved from the DevOps department to the Platform department as it aligns more with what we are trying to provide. A Platform for developers.

That said we essentially can speak sysadmin and can speak developers. We trust sysadmins with network, linux image and more specialist topics. We make tools for both sides and try to make them work together often sitting in the middle and negotiating.

[dielectrikboog]

Call them SREs and cross-train SWEs into it. It’s not a toothless distinction even though it seems like one. You absolutely, positively will hire better staff with better deliverables if you frame the work as “a software engineer focused on operational integration,” which SRE understands more.

SREs like to build platforms for exactly the same reasons you’re touching. You sound like you’re halfway there already. I strongly suggest the Google book, with “I am not Google scale” written in Sharpie on the cover for help digesting it.

[aprdm]

In my understanding SRE is more related to "keep the lights on and systems running", it might be just a different understanding of the nomenclature.

E.g: In my current case the software teams own their ops, my team doesn't ops for them.

We give them a platform of centralized logging, monitoring and etc. so that they can easily ops their services but is not my phone that rings and I am not on call. I am on call if some component of the platform itself fails.

At least my perception of SRE is that they're on call for products.

That said I would frame the work we do as “a software engineer focused on operational integration“.

That does sound like a good book and I will add to my to read list.

[dodobirdlord]

> In my understanding SRE is more related to "keep the lights on and systems running", it might be just a different understanding of the nomenclature.

SREs at Google own production in a very deep sense. They are decision makers on things like when teams can deploy, how frequently, what dependencies they can use, and possibly most significantly, who gets SRE support and who has to handle their own on call rotation. They also build monitoring and reliability services and tools.

Google also employs traditional Ops people, but not as many as you might suspect. When SREs look at traditional Ops work, they see a threat to reliability and a target for automation. The mantra is that the "E" isn't for show, and that SREs are software engineers who specialize on the topic of running highly reliable services. One of the things the SRE book stresses is making sure that SRE teams aren't so bogged down in oncall responsibilities that they don't have time to work on automating their oncall responsibilities.

[aprdm]

Yup absolutely and I do love the SRE book and adopt many practices of it.

Might be my own bias towards the SRE word.