"SRE" doesn't seem to mean anything useful any more

People need operations staff, people don't like operations staff and keep trying to treat them like developers.

But, operations staff do and have always developed software, just internal software for glue or orchestration, and they work differently to regular software developers in that their customers are usually themselves to meet an internal objective of reliability, stability or ease-of-use for developers.

It's interesting to me, because I'm a bit longer lived it seems and have been tied to industry for a long time, and I see the treadmill grinding along continuously;

Sysadmins (different from system operators) were usually among the most senior developers who ended up knowing how operating systems and compute worked fundamentally. Over time this eroded and eventually you had helpdesk people being labelled as sysadmins.

Then "DevOps" emerged as a job title, which meant a dozen things to a dozen people, and the same issue happened, it was the same operational needs and the same operational solutions, just with better tools as the passage of time allowed better tools to exist.

Then SRE, which ironically was devised before DevOps was, which did exactly the same thing of trying to turn operations problems into the easier to reason about software development space.

But still, it's operations folks, people who are more responsible about an outcome and a continuance than they are about delivering a feature.

But Managers genuinely can't reason about anything other than features, so a cost center it becomes and eradication is desired, and the treadmill begins again.

So, SRE's, who embody essentially the same characteristics as early sysadmins (but with large budgets and better tools) will eventually become system operators, who will eventually become helpdesk and eventually replaced by some new title that insists that "SREs never wrote code, and this next generation will!".

The author is experiencing the exact same thing I did over a decade ago when "sysadmin" became unfashionable and everyone told me that "sysadmins can't code", despite working in teams of sysadmins who wrote precursors to kubernetes/nomad, on bare-metal, in perl on Solaris.

Will be interesting to see what the next iteration will be called, the author will just need to alter her vernacular.

It still means mandatory, potentially grueling, on-call rotations.

Such a overused quote, but still, seems to apply to "position names" as well:

> There are only two hard problems in computer science...

>Then "DevOps" emerged as a job title, which meant a dozen things to a dozen people, and the same issue happened, it was the same operational needs and the same operational solutions, just with better tools as the passage of time allowed better tools to exist.

DevOps was/is not just better tools, it's the same team that builds the software, operates the software (and underlying infrastructure). Maybe when it became a job title (later) then it just became a rebranding of the ops team.

DevOps has that meaning to you, maybe.

I would implore some reading into the origin.

Cliff notes version, things that happened around the same time:

* Dev+Ops days is made by Patrick Dubois, the intent was for Sysadmins to use Agile ("Agile Systems Administrator" was the desired job title), he used "dev"+"ops" to signify a unification in working methodology, not as a team

* 10+ deploys a day from Flickr; where the authors are in a single unified team of sysadmins and developers.

Like Agile, people always claim you're "doing it wrong", which I find ironic given that the portmanteau was created to bring Agile to systems administration itself. However, devops was confused right out of the gate.

Your definition is the 10+ deploys a day talk.

I actually wrote a blog post about this:

https://blog.dijit.sh/devops-confusion-and-frustration/