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.
Same here, being that developer on the team that would embrace build and deployment scripts, means that for the last 30 years, I have always to jungle around, am I a developer, a systems administrator, network engineer, or whatever is fashionable as term for upper management.
The worse part of the fashionable job titles is that both management and HR love to put people on little boxes, and generalists are a big headache for them, on top of deteriorating the actual original meanings of these roles.
>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.
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.
You need to also look into why DevOps became a thing. Because devs were sick of the BS dealing with Ops teams (want a server, that will take 6 months to provision). So devs decided they could do it themselves (with better tools).
But if AWS originates from the ops teams of Amazon, then perhaps they were just doing Ops better than everyone else. They chose not to be just a cost centre, and find ways to become better.
Not scale in terms of your company scaling. Only scale in terms of number of companies using the same off the shelf tooling.
The difference with those tools is that they were off the rack and not bespoke. There were plenty of bespoke systems before, used in fewer places because bespoke systems are expensive.
Perhaps they would’ve spent more effort making software not suck if they still had that constraint. Instead, now we get the modern dumpster fire because more resources are an HPA call away.
> DevOps was/is not just better tools, it's the same team that builds the software, operates the software (and underlying infrastructure)
Not happening in any of the companies I worked for as a contractor or subcontractor. In those companies at best dev teams have nowadays some additional capability to deploy to dev/test instantly (so they do their own CI/CD pipelines and manage dev infra via Terraform or whatever) but production is always handled by a "DevOps" team which does not touch the application code at all.
This is especially visible in companies that outsource their development to software houses / individual contractors (B2B stuff, most of the folks I interact with).
These setups are frankly asinine. Often come with another contractor and an entirely separate org to handle service/support. And then management wonders why relatively simple applications take forever to ship, changes take even longer and operating costs are astronomic ("back in the day four guys could do this" - they still can, you just don't let them).
> It's interesting to me, because I'm a bit longer lived it seems and have been tied to industry for a long time
> The author is experiencing the exact same thing I did over a decade ago
> the author will just need to alter her vernacular
If I'm not mistaken, the author is older than you and has been in the industry longer. She's complaining about this topic specifically because she was a Google SRE back when SRE was first becoming a thing.
The older term "Systems Programmer" (which still exists primarily in academia, I had this title a few years ago at a university) has always felt more accurate to me as the "high level operations person who has programming as a primary skillset" job that the original SRE job description seemed to be aimed at.
That's because it's difficult to really define a job in IT with clear description along with set roles and responsibilities.
In some orgs, it's the title that dictates what you can/can't do.
In some orgs, eventually your title is decided based on your role/responsibilities.
In many orgs, your title is just an HR/accounting construct and has no relation to what you do and you do whatever your boss asks you to regardless of what your role on payslip says.
I've had a similar run of titles. The article reads like "I'm an operations person who does serious programming as a hobby."
To expand a little: The job of any "operations" person is to keep the money flowing and avoid wasting money/looking stupid. All that technical circle jerking is just a temporary detail.
Fads come and go, getting functional products in front of customers is forever.
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.