3 ms·

“Dedicated devops” is not devops, never has been. Devops is a culture where, super simplified, you run what you built. “Dedicated devops” is just ops

convolvatron 4y ago
'devops' means I'm going to hire you ostensibly to develop software, but in reality thats just going to be your '10%' time if there aren't any operational fires burning too brightly.
- dilyevsky 4y ago
  What percentage that works up to is totally up to you and that’s the whole point
- dijit 4y ago
  “Devops” means build engineering to some Sysadmins who know a bit of python to others Developers who can configure nginx to others. Or a culture; to yet more people. Clearly it doesn’t have meaning if it’s so undefined. FWIW the progenitor of the word defined it as “agile systems administration”: what you’re talking about is the 10+ deploys a day talk from flickr; which doesn’t mention devops at all (despite the conference existing prior).
- Aeolun 4y ago
  If you are hired as DevOps, or if your organisation does DevOps without any dedicated personnel, and all the devs are now DevOps, you are damn right that everyone'd be fighting all the fires first. The idea being that the people building and running the application are incentivized to prevent fires as much as possible. As opposed to completely separate teams, where the devs have zero incentive to prevent fires. Everyone judges them on features/sprint, so optimizing for that is perfectly logical.
  - wizofaus 4y ago
    That's not been my experience at all. Developers absolutely do need to be roped in to help put out fires when the application is misbehaving, and most of us quite assuredly want to keep that to a minimum. And having reliable, smooth and well-regulated DevOps processes is a huge enabler for ensuring robustness and minimizing the chance of bad code getting deployed to production.
wizofaus 4y ago
I get some people use the term that way, but in our case, our guy really did spend ~50-60% of his time developing IaC and other deployment scripts/tools (in various languages), and the rest handling the operational side of things. He occasionally touched the application code as needed (renaming configuration variables etc.), but he didn't do feature-level development, nor was he interested in doing so.
- ketzo 4y ago
  This was also my experience. I used to work in an org with about 200 engineers, supported by a DevOps team of ~6 devops engineers. They spent (very roughly) half of their time doing operations, and half of their time writing software to make devops easier. Every other month they’d announce some new tool for us to run automated tests or speed up builds. It was awesome, and made our developers more likely to do their own portion of the ops work.
  - techsupporter 4y ago
    > They spent (very roughly) half of their time doing operations, and half of their time writing software to make devops easier. This is what happens in my (non-tech-industry, but heavily invested in tech stacks) employer. A previous manager decided we were no longer System Administrators but now DevOps Engineers. But none of us develops code for our features and none of us wants to develop code for features. We want to build and maintain the infrastructure on which the code runs. Some of it has to be run in-house because we deal with medical information and all that entails. Our current manager describes not as Developer Operations but Developing Operations. We develop the infrastructure and tooling that our code writers need and do everything we can to get the moving parts out of their way. If the code written by the code writers fails, it is their responsibility to deal with it but if the infrastructure underpinning that code fails, my team has failed.
- dilyevsky 4y ago
  Ime this unravels quickly as the team and stack complexity grows and product engineering starts shipping software that’s very difficult/expensive to operate. The whole idea behind devops was to avoid this death spiral by giving engineers ownership and responsibility to run their own software. The problem was (still is) that off-the-shelf tooling is just not there and requires very skilled/experience devs to use it effectively. Hence dedicated teams got created and the whole thing died on the vine. Devops as a movement simply doesn’t scale.

convolvatron 4y ago

'devops' means I'm going to hire you ostensibly to develop software, but in reality thats just going to be your '10%' time if there aren't any operational fires burning too brightly.

dilyevsky 4y ago
What percentage that works up to is totally up to you and that’s the whole point
dijit 4y ago
“Devops” means build engineering to some Sysadmins who know a bit of python to others Developers who can configure nginx to others. Or a culture; to yet more people. Clearly it doesn’t have meaning if it’s so undefined. FWIW the progenitor of the word defined it as “agile systems administration”: what you’re talking about is the 10+ deploys a day talk from flickr; which doesn’t mention devops at all (despite the conference existing prior).
Aeolun 4y ago
If you are hired as DevOps, or if your organisation does DevOps without any dedicated personnel, and all the devs are now DevOps, you are damn right that everyone'd be fighting all the fires first. The idea being that the people building and running the application are incentivized to prevent fires as much as possible. As opposed to completely separate teams, where the devs have zero incentive to prevent fires. Everyone judges them on features/sprint, so optimizing for that is perfectly logical.
- wizofaus 4y ago
  That's not been my experience at all. Developers absolutely do need to be roped in to help put out fires when the application is misbehaving, and most of us quite assuredly want to keep that to a minimum. And having reliable, smooth and well-regulated DevOps processes is a huge enabler for ensuring robustness and minimizing the chance of bad code getting deployed to production.

wizofaus 4y ago

I get some people use the term that way, but in our case, our guy really did spend ~50-60% of his time developing IaC and other deployment scripts/tools (in various languages), and the rest handling the operational side of things. He occasionally touched the application code as needed (renaming configuration variables etc.), but he didn't do feature-level development, nor was he interested in doing so.

ketzo 4y ago
This was also my experience. I used to work in an org with about 200 engineers, supported by a DevOps team of ~6 devops engineers. They spent (very roughly) half of their time doing operations, and half of their time writing software to make devops easier. Every other month they’d announce some new tool for us to run automated tests or speed up builds. It was awesome, and made our developers more likely to do their own portion of the ops work.
- techsupporter 4y ago
  > They spent (very roughly) half of their time doing operations, and half of their time writing software to make devops easier. This is what happens in my (non-tech-industry, but heavily invested in tech stacks) employer. A previous manager decided we were no longer System Administrators but now DevOps Engineers. But none of us develops code for our features and none of us wants to develop code for features. We want to build and maintain the infrastructure on which the code runs. Some of it has to be run in-house because we deal with medical information and all that entails. Our current manager describes not as Developer Operations but Developing Operations. We develop the infrastructure and tooling that our code writers need and do everything we can to get the moving parts out of their way. If the code written by the code writers fails, it is their responsibility to deal with it but if the infrastructure underpinning that code fails, my team has failed.
dilyevsky 4y ago
Ime this unravels quickly as the team and stack complexity grows and product engineering starts shipping software that’s very difficult/expensive to operate. The whole idea behind devops was to avoid this death spiral by giving engineers ownership and responsibility to run their own software. The problem was (still is) that off-the-shelf tooling is just not there and requires very skilled/experience devs to use it effectively. Hence dedicated teams got created and the whole thing died on the vine. Devops as a movement simply doesn’t scale.