4 ms·

> the entire point of DevOps was that "operations" isn't a job or role anymore and has instead become a task that should be done by the developers. This akin t

> the entire point of DevOps was that "operations" isn't a job or role anymore and has instead become a task that should be done by the developers. This akin to saying "frontent developer isn't a role anymore - both frontend and backend should be handled by a full-stack developer". This works for small companies/projects, but bigger ones can benefit from specialization and division of labor. Body of knowledge required to be a decent software developer and a decent ops engineer is too big to fit into one head. I've seen ops work being done by developers without ops experience and more often than not it was ugly - they didn't had enough experience/knowledge (and time/incentives to gain them) to do ops work well. To me the best part of DevOps isn't about roles but about team structure - splitting all Dev in one department and all Ops into another usually is a bad idea. And a failure of this split was a motivation to start DevOps movement. Having Ops embedded into Dev teams in my experience works much better.

dragonwriter 4y ago
> but bigger ones can benefit from specialization and division of labor I think it is central to the DevOps concept is that dev vs. ops segregation—at least on the small team level, perhaps not at the individual level—is a counterproductive division of labor that inherently fosters micro-optimizations on both sides of the divide that are counterproductive to effective value delivery. On a continuously available software service, the lowest-level product team should own it's components soup to nuts rather than having a dev team throwing hopefully-deployable code over the wall to an ops team.
- ezrast 4y ago
  And that's great until you have three-ish "lowest-level" product teams and they're all managing not only their own production systems, but their own deployments and testing pipelines and monitoring stacks and secrets management. At some point, you need to start unifying that stuff to keep things manageable, and if those systems are everyone's responsibility, they're no one's. So you make another team for whom the internal shared infrastructure is the product, and the rest of engineering are the customers - they still write their own Terraform modules and whatnot, but they run them on DevOps-supplied platforms. That seems to be what modern DevOps is becoming.
  - pas 4y ago
    these are not mutually exclusive. if those product teams are under one big umbrella then nothing stops the one holding the umbrella (C-level or whoever) to set the standard. you can use these languages, these CI tools, these package repositories, etc. if you need something exceptional ask. the important aspect is that there should be enough working knowledge about these tools/processes/systems in those teams that they can work efficiently, and they can respond as the whole business evolves. (eg. scale up/down, extract and hand over or accept and integrate components, integrate other APIs, etc) > and if those systems are everyone's responsibility, they're no one's. again, there's a cut off eventually. for example many companies just use GitLab for CI. at that point it's up to the big umbrella to decide whether they want to be in one or many GL orgs. > That seems to be what modern DevOps is becoming. sure, but that cutoff seems to be infrastructure vs product. which seems a bit more healthier than cutting the software lifecycle in half.
  - citrin_ru 4y ago
    One can have both - team(s) which own shared infra like k8s, monitoring servers, CI/CD servers e. t. c. and ops embedded into development teams.
pas 4y ago
> Body of knowledge required to be a decent software developer and a decent ops engineer is too big to fit into one head. the usual answer is that in a good agile team everyone should be a little bit T-shaped https://www.cybermedian.com/scrum-team-i-shaped-vs-t-shaped-people/ https://www.cybermedian.com/scrum-team-i-shaped-vs-t-shaped-... of course domain experts are real (or what's the term nowadays?), so specialization makes sense. comparative advantage and all. but the idea is to lower the (coordination, communication, conflict due to inevitable misalignment between separate teams) overhead by "onshoring" the basics (eg. writing tests, basic CI stuff, deploying) the devops manifesto (which allegedly does not exists, but you get the point) basically calls for giving people tools, permissions and authority to do these basic things, giving teams ownership of their stuff. and of course this doesn't mean fire every sysadmin on sight :D (even if that would definitely help with the process of re-owning some ops taks to dev people)

dragonwriter 4y ago

> but bigger ones can benefit from specialization and division of labor I think it is central to the DevOps concept is that dev vs. ops segregation—at least on the small team level, perhaps not at the individual level—is a counterproductive division of labor that inherently fosters micro-optimizations on both sides of the divide that are counterproductive to effective value delivery. On a continuously available software service, the lowest-level product team should own it's components soup to nuts rather than having a dev team throwing hopefully-deployable code over the wall to an ops team.

ezrast 4y ago
And that's great until you have three-ish "lowest-level" product teams and they're all managing not only their own production systems, but their own deployments and testing pipelines and monitoring stacks and secrets management. At some point, you need to start unifying that stuff to keep things manageable, and if those systems are everyone's responsibility, they're no one's. So you make another team for whom the internal shared infrastructure is the product, and the rest of engineering are the customers - they still write their own Terraform modules and whatnot, but they run them on DevOps-supplied platforms. That seems to be what modern DevOps is becoming.
- pas 4y ago
  these are not mutually exclusive. if those product teams are under one big umbrella then nothing stops the one holding the umbrella (C-level or whoever) to set the standard. you can use these languages, these CI tools, these package repositories, etc. if you need something exceptional ask. the important aspect is that there should be enough working knowledge about these tools/processes/systems in those teams that they can work efficiently, and they can respond as the whole business evolves. (eg. scale up/down, extract and hand over or accept and integrate components, integrate other APIs, etc) > and if those systems are everyone's responsibility, they're no one's. again, there's a cut off eventually. for example many companies just use GitLab for CI. at that point it's up to the big umbrella to decide whether they want to be in one or many GL orgs. > That seems to be what modern DevOps is becoming. sure, but that cutoff seems to be infrastructure vs product. which seems a bit more healthier than cutting the software lifecycle in half.
- citrin_ru 4y ago
  One can have both - team(s) which own shared infra like k8s, monitoring servers, CI/CD servers e. t. c. and ops embedded into development teams.

pas 4y ago

> Body of knowledge required to be a decent software developer and a decent ops engineer is too big to fit into one head. the usual answer is that in a good agile team everyone should be a little bit T-shaped https://www.cybermedian.com/scrum-team-i-shaped-vs-t-shaped-people/ https://www.cybermedian.com/scrum-team-i-shaped-vs-t-shaped-... of course domain experts are real (or what's the term nowadays?), so specialization makes sense. comparative advantage and all. but the idea is to lower the (coordination, communication, conflict due to inevitable misalignment between separate teams) overhead by "onshoring" the basics (eg. writing tests, basic CI stuff, deploying) the devops manifesto (which allegedly does not exists, but you get the point) basically calls for giving people tools, permissions and authority to do these basic things, giving teams ownership of their stuff. and of course this doesn't mean fire every sysadmin on sight :D (even if that would definitely help with the process of re-owning some ops taks to dev people)