"DevOps" = "sysadmin that can code scripts".
Whatever your conceit, that's in fact what the term means in practice.
Whatever your conceit, that's in fact what the term means in practice.
That was one reason that Perl became so popular among sysadmin back in the early 90's: it was a really useful language in which you could do much the same as you could with (and had a syntax which was similar to) shell scripting, sed, and awk, which were tools that were popular among sysadmins up 'till then.
Programming is a subset of skills within the sysadmin role.
You'd be surprised. A large chunk (say, more than 50%) of the sysadmin job market are guys that can set up a Windows LDAP and/or some Cisco and Wi-Fi equipment, but no more.
It's why the 'DevOps' moniker was invented, to differentiate the old-school Unix sysadmins from the LDAP-and-Exchange guys.
It's bridging the gap between software developers and sysadmins where devops falls into place. Taking applications and optimizing their environments, rollouts, versioning, reliability of deployments, reduction of downtime, automating server provisioning, etc.
IMO the best devops are software devs with some sysadmin experience.
To me DevOps: One must understand the build system, stack, and the minutiae related to maintaining that build stream. It's a lot of work and at least in the past was more of a developer responsibility and not a "System Admin" type responsibility.
System Administration: Security, User Accounts, Policy, Backups, Network Configuration, Automation, Reliability.
Sure there is some overlap but these used to be completely separate functions and with good reason there was a lot to understand about each workflow.
Modern workflows (K8s, AWS, Docker, VMs, Jenkins, CI, TDD) have mostly take the "System" out of system administration while improving reliability and speeding development while (I think) suffering security. But that's another post or maybe I will write an article about it.
Its not like they ran the backups at midnight manually.
One type writes a script to back up systems. Depending on their level of expertise they may also include error checking and tie it into the monitoring/alerting system so we know when the backups don't run correctly.
Another type buys backup software, and configures it to back up their systems.
Each type has pros and cons, and each may feel superior to the other. However the ones who haven't coded may find themselves ill-suited to moving to a job where they are expected to be more of the first type, the coding sysadmin.
When interviewing prospective sysadmins, I've tried to tease out whether they are a "maker" or "doer" type of person. The makers tend to be more scarce, and the doers may be ignorant of how much they could be learning and experiencing if they widened their horizons a little.
It may sound like I'm very dismissive of the doers. I'm not, a good team is going to have a mix and have different levels of expertise too.