What I don't want to mess with is the "DevOps" tools, like Docker and rest of cloud orchestration stuff. It's a very complex field and I couldn't care less. If I work on a project like that there's always somebody who can do that kind of setup.

Docker and other Docker-like containers like Rocket don't have anything to do with DevOps per se, but they facilitate easier automated deployment of said configuration artifacts. Technically, Docker & Co. are just remedies to classical DLL hell situations, and have been used mostly for development and software evaluation purposes. Though they technically don't provide much more isolation than simple chroot-jails, increasingly they're also used in place of VMs because of density reasons, eg. because you can run a whole bunch of services on a single machine with less footprint than VMs (on Linux, that is).

The frenzy with Docker and the other cloud orchestration stuff, as you say, is IMHO mostly because of Sillycon startups with insane amounts of venture capital buying their way into people's minds.

Edit: ok, the last remark was a bit snarky; sure there's a need of mass-digestible tool for collaboratively editing DevOps artifacts and deployment plans, but I don't know any I like; feel free to point me to one (preferably without JSON and/or yaml configuration files)

If you're a large business you should be automating your sysadmins with devops/SRE techniques. If you're a small business you should be outsourcing that work to companies that have automated it for you.

That's why cloud providers and associated services have seen enormous growth.

Chef etc. aren't "home repair." (Well, maybe Docker, and it shows.) They're a way of expressing subject matter knowledge. Still gotta be a developer to do that expressing in a way that isn't going to kill you, either directly or because you write code that your fellows burn you at the stake for.

We're lucky that we work in an industry where our work is most likely not going to kill people. We don't have to be licensed to make a claim of who we are or what we can do. But it would be very disingenuous for me to call myself a professional software engineer just because i've written hundreds of thousands of lines of code, and for you to call yourself a sysadmin because you've set up some software. The mark of a professional is understanding at a deep level all of the hidden detail that goes into the work, and if we hold them up to a standard, the titles will reflect that.

So, how often are software developers different from sysadmins? They're always different. They're completely different practices. As a person, you can indeed have two separate successful careers and become both, but that doesn't have anything to do with devops, which is merely the practice of dev and ops collaborating together.

"Set up some software," though? The condescension is both unnecessary and built upon some pretty shaky projections on your part. Can we not dance that dance, please? (ETA: Not least because I think your posts, for the most part, are really good and I have a lot of respect for you, especially around security topics.)

In actual fact, the complexity of software design is antithetical to the job of system administration. If at all possible you should use the least code possible to do a given job, and rely on the reuse of tools to serve various functions. This is not coding, just like auto repair is not engineering. If you're writing code you are not adminning, you are developing.

There is a time and a place for software development in Ops, but it should be based around projects led by teams to serve specific functions that existing tools won't solve, again similar to auto repair because some tools are needed simply to repair things more efficiently, but then you use those tools and don't keep engineering new ones. The distinction is small but highly important, because code is often a source of headaches in Ops. This is coming from a guy who is usually hired to write code for Ops departments.

A software developer can of course perform some of the functions of a sysadmin, but again the complexity of the whole becomes too much to understand just by doing single tasks. Either job is too complex to learn without a lot of study.

I just find comparing the two in the context of one becoming the other invites oversimplification of either role, and devops doesn't help that comparison.

I agree, on both counts--and you should write the least code possible and reuse the most tools possible when you're building a web app, too! And when I am managing systems and infrastructure, I am reusing tools that are configured and operated through the expression of domain-specific code in Ruby. When I'm solving a problem, I'm writing code in Chef or in Cfer/CloudFormation (if I'm touching a machine by hand that's outside of my burn-it-down test environment, something's going really, really wrong). I'm consciously writing that code in such a way that I can put it into an automated test environment based on preconditions and postconditions that map to the business logic of the system to ensure correctness when that code is then changed. If I need to solve a related problem later, I'll generalize the code for least-effort reuse at that point.

This is literally software development, to me. That the output involves a configured system instead of a web app or whatever is orthogonal to being software development. It still feels like you are drawing a distinction without a difference.

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.

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.

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?

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.

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"?