My impression is many sysadmin at the time didn't really understand the systems they were dealing with - that kind of problem solving, hacking, and mapping the territory comes with software engineering. So why not just hire software engineers?
You think if a sysadmin does not understand the topic a software engineer magically will? I think the biggest obstacle of understanding systems the level SREs do is lack of proper documentation and formal education. This is why Google introduced the SRE university and also created the following doc.
What I mean by proper documentation is that you do not have all the knowledge in one place. I have spent countless hours of preparing to SRE interviews by reading source code and hunting for additional write ups that explain various OS functions, file systems, networking details. The amount of text you have to go through to get the knowledge is intense. The best way to become an SRE is to be hired one at Google or Amazon and just learn from your senior co-workers. Catch 22. :)
My rule of thumb is that the difference between a sysadmin and a programmer is that the sysadmin has read the documentation for all of software they use.
I don't see either path as having an overwhelming advantage.
What happened here is that the scale of sysadmin tasks escalated to the point where software engineering skills brought some advantage. It did not, though, negate the importance of traditional sysadmin skills.
The best people in this space are those that can bridge both worlds. Not just "SRE" either. Devops is also a hybrid role, as is performance engineering.
Look at Adrian Cockroft's background as an example.
DevOps is a concept, not a role. It means breaking down the silos and allowing processes, ideas, capabilities to run across both SWE & operations teams. I never knew a really first-class *nix sysadmin who wasn't also a kernel hacker, so this isn't anything new, it's just got a label.
Probably the most devops-y thing you can do in an applications environment is operate a continuous delivery pipeline.
The most un-devops-y thing you can do is start a devops team.
That's a great example. There's nothing in those job listings that wasn't, conceptually speaking, in the job description of a system engineer or sysadmin thirty years ago.
In this usage of "DevOps" it's a buzzword, and I recommend you should avoid anyone who puts buzzwords in your job title, because it speaks volumes up front about their culture and values and clarity of thinking.
I really do like the descriptor Site Reliability Engineer, though, for exactly the same reasons.
It allows the company to save on dedicated resources in my experience.
A lot of first-class *nix admins in my generation have a problem dealing with dev ideas in system context. In the company I am at now we have gone a step further and allowed dev/mgmt to control ops|prod and reserved system to
sidestep the crapulence of this concept.
