Hacker News Reader

Comment by bthornbury | Hacker News Reader

Not the same at all. Let me rephrase the question.

Reading the article, the sysadmin is described as the person who constructs and maintains the environment the code runs in, including the physical machines, but also things like dependency management (I infer).

Given that just about everything except the physical machine can be handled through devops automation (from experience), and those things don't require "special" skills other than docker/ansible knowledge, why are sysadmins still considered separate from software devs?

On a more opinionated note, I think that using people, and not code to setup the operating environment of their application is pretty inefficient nowadays.

View on HN

I started as a dev many years ago, then moved into sysadmin / devops stuff for over a decade, and then moved back to more hands on dev stuff again a few years ago. I think your statement that "those things don't require "special" skills other than docker/ansible knowledge" is over-simplifying things a bit.

Writing a production quality Dockerfile or Ansible Playbook requires more than just a bunch of "apt-get install" statements. You need a bunch of knowledge about how each bit of software should be configured and tuned for each individual use-case.

Once it's been written, then the devs can happily automate all the things as much as they like. Writing it in the first place is where a lot of what was traditionally sysadmin knowledge comes into play.

Anyone with a bit of patience and practice can follow a recipe in a cook-book. Not everyone can write one.

I'll agree that I definitely oversimplified it. I think what I was getting at was that it was a similar set of skills to other types of software development.

Thinking like this is what leads to tens of thousands of Mongo databases being exposed online.

Anyone can follow a "how to install X" guide and install a few packages and get a working config to get going and then automate it with their tool of choice but that doesn't come anywhere close to a production ready system.

When your job focus is shipping product that's all you care about, get it out the door as fast as possible so why learn anything more than the bare minimum?

Getting it out the door will make you learn faster. The choice to stop learning is a personal one IMO.

Software is complicated and error prone and it takes a good amount of skill and time to write it well. Personally, I'm not impressed at all with most software made in an Ops environment. I think it usually sucks and that sucky quality, along with the complexity of debugging and maintaining it, makes it a net deficit to productivity. I have been writing software in Ops for a long time and it is just annoying how little work is done correctly in this space. I think most Ops automation is so error prone that you might as well hire an intern to stare at your network and you'll get as good if not better system stability.

In fact, this is how Ops used to work. You'd use humans to oil the machinery of the basic automation you put in place, and they were damn good at keeping uptime high and catching problems nobody thought of in their automation. Now people just automate and pray, it seems, and then play catch-up indefinitely, or waste time redesigning.

We totally automate the physical machines too. But wherever possible by using tools, not writing software. Honestly I wouldn't want to insult the practice of software engineering by comparing my work to theirs.

> Software is complicated and error prone and it takes a good amount of skill and time to write it well.

This we can agree on.

> Personally, I'm not impressed at all with most software made in an Ops environment. I think it usually sucks and that sucky quality,

Not sure what is an ops environment although I'll agree with the general statement that most software I see sucks and is of sucky quality, but I think that relates back to your first point.

> In fact, this is how Ops used to work. You'd use humans to oil the machinery of the basic automation you put in place, and they were damn good at keeping uptime high and catching problems nobody thought of in their automation. Now people just automate and pray, it seems, and then play catch-up indefinitely, or waste time redesigning.

I'm not proposing that the rise of devops precludes the need for people specialized in it's use and implications. Instead that sysadmin is essentially becoming a branch of software engineering with the rise of devops. When setting up a system IS writing code, why is the "software engineer" different from the "sysadmin"?

Reply on news.ycombinator.com