4 ms·

I'm writing this as a DevOps/SysEng/whatever you prefer: I think there are two big type of developers groups in the industry, and two ways to think about these

I'm writing this as a DevOps/SysEng/whatever you prefer: I think there are two big type of developers groups in the industry, and two ways to think about these issues. The first group advocates for an ultimate "NoOps" world where every team, composed only by SWE, is responsible for the whole code lifecycle, from inception to deployment to maintenance to decommission. This is aspirational in many, many companies and probably true in a bunch of really good companies. Anyway I still wonder if there aren't tensions there between product/business asking for developer power to bring new features/changes in and developers doing the Operations work beside writing business code. The second group is formed by the developers described in the article, which just focus on their code and need a "developer helpdesk" for everything else related to actually deploying and operating the software written. IME this is how the vast majority of companies work, especially the "normal" ones. Some developer steps "up" and try to understand/do this extra work and they usually rise to the top because they are the "good" engineers.

robertlagrant 5y ago
> every team, composed only by SWE, is responsible for the whole code lifecycle, from inception to deployment to maintenance to decommission I think this is the original thesis for DevOps.
- darkwater 5y ago
  Yes, absolutely, but it's not actually widely implemented. Orgs does "DevOps" but they are just automating/writing as code some things that previously were done manually by Ops/SysAdmins. Now we have DevOps roles doing that same work but with other tools (Terraform, Cloudformation etc), much more automation, less gruntwork and toll but STILL used as "developers IT" nonetheless.
  - robertlagrant 5y ago
    Not disagreeing :)
- nonameiguess 5y ago
  This isn't true at all, though. Many organizations, especially smaller ones, seem to have taken it this way. Everyone is responsible for everything. But that wasn't the DevOps thesis. The idea was for eliminating silos in the sense that dev and ops would talk to each other continuously throughout the software lifecycle, with developers understanding operational challenges and creating software that didn't just meet functional requirements, but was easier and faster to deploy, change, rollback, and troubleshoot. Ops would understand the pressures of development and create automation systems catered to the specifics of their software stack. It wasn't supposed to mean no more division of labor. Division of labor is a key innovation in human society that enables civilizations to exist. It was supposed to mean the teams in different categories of labor interact throughout and consider each other's needs, and not throw shit at each other over a wall and only ever interact through a ticketing system.
  - twic 5y ago
    I believe that it was supposed to mean no more division of labour, and i believe that based on conversations with people who were early adopters of it ten years ago. This waffly "breaking down the silos" stuff is a later redefinition, i believe reacting to the fact that the original meaning was extremely unpalatable to existing organisations, with existing employees and hierarchies who would be severely disrupted by it.
    - darkwater 5y ago
      But I still challenge the fact that it can really work well for normal performers and not only top notch developers. Taking care of all the phases of a software lifecycle is not an easy task, it has a big enough cognitive load. I understand that this is supposed to be done in (small) teams, but within those teams you still need some degree of separation of labour, you cannot have everybody having wide and deep knowledge of everything software. Well, you can do it, if you are Google and the like and set the bar for hiring really, really high. But that doesn't apply to most organizations and engineers. Not all of us are wicked smart.
    - vajrabum 5y ago
- m1keil 5y ago
  The original thesis was better cooperation between developers and sysadmins (ops). It didn't focus on trying to make operations redundant or transfer every sysadmin into a SWE.
- thesuperbigfrog 5y ago
  It is. The team that writes the code should also deploy the code and get paged in if there are problems in production. That creates a tight feedback loop that requires developers to learn and manage the whole stack, code defensively, and test enough to be confident to deploy to production. Didn't test your code enough? You will be paged in the middle of the night to fix it. It creates a strong incentive to make good decisions because you will be living in the mess you create.
  - cestith 5y ago
    In those cases, though, it's usually a team with some Dev people who know or can learn some Ops and some Ops people who know or can learn some Dev. It's not just laying off all the sysadmins, network admins, stack architects, and all then letting the developers freefall until they find a way to right themselves.
  - cbushko 5y ago
    And this only works if your Ops team provides good tooling for deploying, logging, monitoring and alerting. I have heard of companies deciding to do 'devops' and it turns into a free for all of dev teams having to handle/build things end to end. Everyone loses in that scenario.
closeparen 5y ago
To put some color on the "NoOps" world: it is not that product engineers are directly touching cloud or metal. We have an infrastructure group. It ships a PaaS. It doesn't get involved with a specific tenant of that PaaS unless a product engineer has evidence that there's something wrong with it & escalates a page. Product engineers click the deploy and rollback buttons for themselves.
- darkwater 5y ago
  Thanks for stating this, I think it's exactly what a DevOps oriented org should ultimately achieve. Or at least try to.
lbhdc 5y ago
> every team, composed only by SWE, is responsible for the whole code lifecycle, from inception to deployment to maintenance to decommission This is how it is at my startup. All of the engineers are involved in managing the infrastructure for everything we build. I find it gives me much better insight into my app, and the feedback loop is much tighter since I am in control of everything.
- dilyevsky 5y ago
  Imo anything but that in a fast pace startup will ultimately lead to frustrations / bad blood

robertlagrant 5y ago

> every team, composed only by SWE, is responsible for the whole code lifecycle, from inception to deployment to maintenance to decommission I think this is the original thesis for DevOps.

darkwater 5y ago
Yes, absolutely, but it's not actually widely implemented. Orgs does "DevOps" but they are just automating/writing as code some things that previously were done manually by Ops/SysAdmins. Now we have DevOps roles doing that same work but with other tools (Terraform, Cloudformation etc), much more automation, less gruntwork and toll but STILL used as "developers IT" nonetheless.
- robertlagrant 5y ago
  Not disagreeing :)
nonameiguess 5y ago
This isn't true at all, though. Many organizations, especially smaller ones, seem to have taken it this way. Everyone is responsible for everything. But that wasn't the DevOps thesis. The idea was for eliminating silos in the sense that dev and ops would talk to each other continuously throughout the software lifecycle, with developers understanding operational challenges and creating software that didn't just meet functional requirements, but was easier and faster to deploy, change, rollback, and troubleshoot. Ops would understand the pressures of development and create automation systems catered to the specifics of their software stack. It wasn't supposed to mean no more division of labor. Division of labor is a key innovation in human society that enables civilizations to exist. It was supposed to mean the teams in different categories of labor interact throughout and consider each other's needs, and not throw shit at each other over a wall and only ever interact through a ticketing system.
- twic 5y ago
  I believe that it was supposed to mean no more division of labour, and i believe that based on conversations with people who were early adopters of it ten years ago. This waffly "breaking down the silos" stuff is a later redefinition, i believe reacting to the fact that the original meaning was extremely unpalatable to existing organisations, with existing employees and hierarchies who would be severely disrupted by it.
  - darkwater 5y ago
    But I still challenge the fact that it can really work well for normal performers and not only top notch developers. Taking care of all the phases of a software lifecycle is not an easy task, it has a big enough cognitive load. I understand that this is supposed to be done in (small) teams, but within those teams you still need some degree of separation of labour, you cannot have everybody having wide and deep knowledge of everything software. Well, you can do it, if you are Google and the like and set the bar for hiring really, really high. But that doesn't apply to most organizations and engineers. Not all of us are wicked smart.
  - vajrabum 5y ago
m1keil 5y ago
The original thesis was better cooperation between developers and sysadmins (ops). It didn't focus on trying to make operations redundant or transfer every sysadmin into a SWE.
thesuperbigfrog 5y ago
It is. The team that writes the code should also deploy the code and get paged in if there are problems in production. That creates a tight feedback loop that requires developers to learn and manage the whole stack, code defensively, and test enough to be confident to deploy to production. Didn't test your code enough? You will be paged in the middle of the night to fix it. It creates a strong incentive to make good decisions because you will be living in the mess you create.
- cestith 5y ago
  In those cases, though, it's usually a team with some Dev people who know or can learn some Ops and some Ops people who know or can learn some Dev. It's not just laying off all the sysadmins, network admins, stack architects, and all then letting the developers freefall until they find a way to right themselves.
- cbushko 5y ago
  And this only works if your Ops team provides good tooling for deploying, logging, monitoring and alerting. I have heard of companies deciding to do 'devops' and it turns into a free for all of dev teams having to handle/build things end to end. Everyone loses in that scenario.

closeparen 5y ago

To put some color on the "NoOps" world: it is not that product engineers are directly touching cloud or metal. We have an infrastructure group. It ships a PaaS. It doesn't get involved with a specific tenant of that PaaS unless a product engineer has evidence that there's something wrong with it & escalates a page. Product engineers click the deploy and rollback buttons for themselves.

darkwater 5y ago
Thanks for stating this, I think it's exactly what a DevOps oriented org should ultimately achieve. Or at least try to.

lbhdc 5y ago

> every team, composed only by SWE, is responsible for the whole code lifecycle, from inception to deployment to maintenance to decommission This is how it is at my startup. All of the engineers are involved in managing the infrastructure for everything we build. I find it gives me much better insight into my app, and the feedback loop is much tighter since I am in control of everything.

dilyevsky 5y ago
Imo anything but that in a fast pace startup will ultimately lead to frustrations / bad blood