1. 11

  2. 5

    I still remember when I joined my first job and my CTO told me “we don’t have any sysadmins; the developers are responsible for getting their code out and maintaining the infrastructure”.

    At the time I thought I knew better and tried to hide a smirk, but with time I’ve grown to appreciate this mindset a lot. It makes the whole setup so much more productive when the devs (at least the ones writing backend code) can deploy code and reason about infrastructure.

    1. 1

      the developers are responsible for getting their code out and maintaining the infrastructure

      Getting their code out, totally agreed, but maintaining the infrastructure ?! Most of my devs teammates would leave the company if they had to do so, on purpose or not… Writing a Dockerfile or some shell scripts is everyone’s duty, but migrating a database, configuring VLANs, reviewing security policies seems like something that many devs are really bad at and have enough to deal with on the software side… Maybe this gets easier when using only PaaS and SaaS offerings, but we’re doing mostly self-hosted for few reasons and I definitely don’t think any devs in my company would be able to help.

      1. 2

        Yep, one condition is you need to be using PaaS. We were using AWS so that made a difference. But still, configuring the subnets, handling databases, backups, security groups, VPNs, this was all part of the job description if you joined as a backend engineer.

        The thing is it’s not all that difficult if you’re using the proper tools. If you’re using AWS, provisioning infrastructure is easy. Throw Salt on top of it and you have infrastructure as code. Most productive environment I’ve ever been a part of.

    2. 3

      Maybe it’s just a symptom of being blissfully hidden from the real world in academia, but I quite like that we still have sysadmins. I can see an advantage to the developers also doing infrastructure if what they’re developing is something like Netflix, where the code is tightly interwoven with the infrastructure, to the extent that the whole product more or less is just the infrastructure. But that’s not every use-case. I run simulations on a cluster sometimes, and I know enough about the cluster to get around and understand something about its performance, but maintaining the cluster is really a pretty different skill, and it’s not clear it would improve my scientific work for me to also be the cluster maintainer.

      I’ve heard similar trends in at least some companies. For example Google very much abstracts away its infrastructure, and has separate teams maintaining it. So you can do things like run a Bigtable query resting assured that somewhere under the hood, invisible to you, someone else is making that infrastructure work.

      1. 2

        Maybe this is me being overly reactionary, but it seems this article is arguing that as ops gets increasingly deep and specialized, devs should be responsible for doing ops. That’s different from “devs should be responsible for assisting with ops”, which seems reasonable to me: devs should know how deployments and monitoring work, etc. But software development and software ops are both vast and complex fields. I can’t imagine a person doing both will be anywhere near as good as a person doing either.

        One anecdote I have is that one of our products was set up entirely by devs without any input from our one ops guy. They did it in docker on AWS, which they said was much simpler and easier struggling with Chef. From my understanding, it’s been a lot easier to build on. On the other hand, they haven’t managed to add async jobs because their infra makes that almost impossible. They also have issues with autoscaling, deployments, and their vpc configuration. Would they have had these issues if an ops specialist was involved from the start?