Ask HN: Why was system admin re-branded as devops?

As a recovering sysadmin, I'd say it's not just a rebranding. Sysadmin work was a mix of hardware, networking, OS, and app operations. With the rise of AWS, etc, a lot of that work got spun off to cloud operators. The "cattle not pets" shift removed another chunk of it. So true devops work is more applying developer thinking to what was left of operations.

But I want to address this part:

> If developers are expected to take more roles, doesn't that turn development into "second class" work if no one is left to fill a dedicated role for software development?

The answer is no. My dad started writing software in 1968. From the way he tells it, good developers never just threw things over the wall. They made things for people to use, things that ran efficiently within the constraints of the platform of the day.

I feel the same way today. Devops approaches give teams control over (and responsibility for) the whole lifecycle of the software they write. That's great! Instead of wondering what happens over in ops-land and hoping we get it right, now we can make sure it's right. And this is aided by the rise of the observability movement, giving developers the ability to see inside the running software.

To my mind, there's no such thing as "dedicated" software development, where it happens in isolation. That's like wanting to cook food without caring whether people eat it or how they're enjoying it. I think it's great that teams are expected to operate what they build, and are given the right tools for that.

Also, the shift to SaaS also helped devops ascend. 24/7, 5-nine uptime expectations meant it was business critical for Google or Gmail to always be up.

Honestly, to some degree, it is a rebranding which makes me sad. It's a rebranding because companies didn't change their company culture or change the job requirements. Devops is a new job consisting of sysadmin duties and developer abilities, and the time to actually work on things. Worse, as "on-call code janitors", they often are at the bottom of the totem at a company. (As a developer it is important to understand a company's totem. Google has engineers at the top of the totem; Salesforce has sales at the top. Apple puts design at the top.)Denying devops the time to do both makes you complicit in it merely being a rebranding. Denying the devops team both SWE and sysadmin makes for either a dev team or a sysadmin team but not a SRE team.

There are companies that "get it". But there are far more that don't. We, as devops, have no system for "Apple's role id 1234 isn't actually a devops role. If you want want to be a sysadmin, whos paid well, please apply, but it's not the promised land where you, as an individual who wants to live in the CI/CD SRE promised land, want to go.

Thus, it's ~meaningless everytime I see the string "devops" in a job posting because without further interrogation, I can't know if the job is dev, or ops, or devops. Which is where it actually counts.

Yes, you're totally right. A lot of the things called "devops" are actually just ops. That sysadmins automate what they can is nothing new. In the early 90s I ran a unix workstation lab and wrote tools that would be familiar in spirit to a lot of things today.

Yeah I like that description.

Dev ops is a tighter connection between development and the life of an application, including monitoring, etc.

I don't think DevOps was really supposed to mean "developers should also do operations" (though, that's a lot of what has actually happened, and you're right that with Cloud Stuff and other third-party solutions like Heroku a lot of specialist sysadmin-era knowledge isn't needed in many places anymore)...

I think it's actually supposed to mean "the people doing operations should also be developers". They should have the technical skills and the agency to create software to solve their problems. And to the extent that sysadmins hacked together perl scripts or bash scripts to solve problems, it is presumed that it would be better if they were more skilled software engineers who would have hacked together better solutions - maybe less arcane, less one-man-band, better abstractions, reusable, less copy-paste, etc... I don't know if that's fair.

I think it's half true and half rebranding. DevOps theory - and the services that go with / enabled it - has really changed how a lot of software teams work. And the rebranding helps with the paycheck, too - which is why all your DevOps teams are now restyling themselves as SREs (and hey, if they actually do some of the SRE stuff then it's a win, right?)

Most devops I’ve run into aren’t doing devops. Devops, against sysadmin, build and manage the systems that manage the systems, hopefully as automations or infra-as-a-service or software defined infra. When you think you’re devops but you’re barely sysadmin you’re probably just an interrupt driven ops person who gets to sysadmin during build-outs or maintenance.

Hah, yah you might have nailed it there

I like your take on the situation and I like the idea of DevOps being a more formalized version of system administration using infrastructure as code. Unfortunately, what I think it is in most places is middle management playing games with the three legged stool. Application design and development is really quite a different discipline than configuration management and administration. And if you want quality across the board those roles will, for the most part, need to be separated.

In the "bad old days" a company would commission capacity studies to see how many server they would need to run the parts of their service in data centers and colos. Then they would buy racks and racks of hardware that all had tags for which part of the system they were destined for. An army of network engineers would make sure that the systems were interconnected to the right routers and switches, and that the networks were appropriately segmented. An army of sysadmins would take all of that raw hardware and would painstakingly follow endless checklists and procedure binders to make sure that each piece of hardware was correctly configured to run its part of the system.

But, with the cloud, you buy hardware, stick a base OS on it, and it becomes an amorphous amount of cpu cores, RAM, and harddrives (or at least we try to make people think it works like that). And if everything now runs in a VM, or a container, you can "just" write software that says "I need 6 database servers, 8 event bus servers, 9 back end servers, and 3 load balancers, and we'll use a CDN for all the static assets." (gross oversimplification). And if you need to reconfigure it to be 5-7-12-5-9, you just stop the old VMs and start new ones. You don't need to follow a checklist to make sure that you've correctly uninstalled MySQL 5.6.9, and need to install MariaDB 10.1.35.

DevOps is a very different mindset to traditional System Administration.

System administration has been going the route that network administration went a few years prior: Automate and turn everything into a process, so you can hire the cheapest possible people that are capable of following a process and using some pre-made tools. Software development seems to be heading that direction too. As someone who spent the first third of their career in LAN/WAN networking, the second third in Solaris and Linux administration, and the last 10 years or so in the embedded and RTOS areas, it's been painful to watch it happen.

When I complimented my teenaged son's new found goth sensibilities, he snuffed and deigned to inform me that in fact he was "emo". So I asked for clarification. Best as I could tell, in his opinion, "goth" is what old people did.

In my experience, a decades ago, many sys admins never wrote programs, not even scripts to automate their work. This was more the case with IBM and similar mainframes and minis. In those environments the networking and various subsystems were complicated enough to require a team just to make sure things worked well. Many enterprise Windows deployments were also like that.

As programmers were increasingly required to administer the machines and networks they worked with, they also started automating their work a lot more than was possible with the rigid enterprise systems. Hence the emergence of the fusion of development and operations in certain cases. I think that the term "devops" can mean different things depending upon the technologies being used at a given site.

It’s a warning. If they call it that, be wary of signing on.

Unless, you know, you like doing ops work all day every day.

I just saw a job description with a Software Engineer title and had this as the description:

"looking for an amazing Engineer who will be responsible for the design, implementation, configuration and support of the software product; including specifying, provisioning and operating our cloud infrastructure"

It's a good company but I probably won't apply because I've no idea if I would be coding or provisioning cloud infrastructure.

I recently did a round of interviews at different companies, most of them small-ish (<100 people). I'm a "pure developer" without any real experience in AWS/Docker/Kubernetes. Even for just plain "Software Engineer" roles, this was consistently a negative mark for me as a candidate. Not an automatic deal breaker, but I think it made the difference in a couple of cases.

> It's a good company but I probably won't apply because I've no idea if

You could ask them when you talk to them...

I've been in my current job for 7/8 years so not really sure how the interview process works. I saw the ad on LinkedIn and it looks like the only option to proceed is to send a CV.

I could only wish the distinction was explicit. It's been my experience that they don't call it that but instead expect the application developers to handle everything which leads to a big ball of configuration management mud.

The same reason that Quality Assurance or Manual testers as been re-branded as “Quality Engineering / Quality Engineers”. Everyone wants to be an engineer and it’s a recruiting tactic.

Do you see many DBAs anymore? I haven’t seen them for awhile, I’ve seen plenty of Database Engineer or Database Developer job postings.

I’d say if they’re going to call you an engineer, asked to be paid like a software engineer.

But the tools and tech are not the same for sysadmins and devops people.

While they are similar my sense is that Sysadmin is an inward facing function supporting the organization whereas devops is outward facing technology dealing with the public on the internet. Each environment has its own challenges.

first software i bought came in a box, disks and manuals.

now i rent an online service.

the coders behind each of these ventures have different tasks : the first, devising installation and operating manuals for an offline world, the second for a day by day continuous challenge of measuring and updating the service's capabilities and market value

The clear answer is that corporations paid a lot of money for this change. Google's AWS's Microsoft's all wanted sysadmin to go away and devops to be in as a way to sell their services. Read more into it

Why so conspiratory. Yes marketing is one aspect of it. But then again a massive amount of sysadmins are required to manage the cloud ops and very often you need a full time devops person on site to replace the sysadmin. In other words efficiency might have gone up but the it budgets did not go down. All in all the world became better with devops for everyone but the ones whos jobs are not as relevant as they were yesterday.