4 ms·

They're doing that thing that happened to DevOps. It started out as a guy who wanted a way for devs and sysadmins to talk about deploys together, so they didn't

They're doing that thing that happened to DevOps. It started out as a guy who wanted a way for devs and sysadmins to talk about deploys together, so they didn't get dead-cat syndrome. It ended up as an entire branch of business management theory, consultants, and a whole lot of ignorant people who think it just means "a dev who does sysadmin tasks". Abuse of a single word to mean too many things makes it meaningless. SRE now has that distinction. You've got SREs who (mostly) write software, SREs who (mostly) stare at graphs and deal with random system failures, and now SREs who use a framework to develop a complex risk model of multiple systems (which is more quality control than engineering).

inquist 2y ago
I think failure mode analysis is definitely part of engineering
ImPostingOnHN 2y ago
Without resorting to any "big-D Devops" definition, I have almost always seen devops referring to "supporting / running the code you write", and have never encountered the definition where dev and ops were 2 different roles. That was what things were like before devops, and coordination on product support and planning wasn't great, hence devops.
- moandcompany 2y ago
  A lot of organizations simply renamed the functional area of "systems administration" or "systems engineering" to "DevOps," and at many of these places, "DevOps" is the new name for the group that software developers will throw stuff over the fence to. The issue with the above names is that they can be applied to a domain or area of practices, or an organizational boundary. In a non-trivial number of organizations, "DevOps" is viewed as a support entity for one or more software development teams, versus software development teams practicing "devops." This applies to many of the *_Ops names in fashion during the past five years or so.
  - znpy 2y ago
    After almost 10 years in the systems engineering / administration / devops / cloud etc space all I can say is: The biggest improvement that devops brought is that it made managers feel dumb, outdated and scared because they were not "doing devops" while everybody else was, so they kinda started listening to sysadmins and what they had to tell. Uh, devops engineers did not come out of nowhere. They did not come out of the ground like mushrooms. Most if not all the "devops engineers" i know are just former sysadmins. They were already willing to do whatever devops was supposed to be, it's just they they were largely ignored. Writing this I just realized that maybe the best way to obtain organizational change is to make management and upper management feel stupid and outdated. Interesting.
    - steveBK123 2y ago
      Hence they have all hired “head of AI” in last 18 months.
      - moandcompany 2y ago
        "What is your AI strategy?" -> "We're hiring a Head of AI"
        steveBK123 2y ago
        It’s the 2020s version of the old IBM line… No one ever got fired for hiring a head of AI.
- stackskipton 2y ago
  I'm Ops type person so I work at companies where there is a split between the two. Ops is a skill not all developers have or frankly, not even mindset to properly do so you will need a team/person to do it. Generally companies don't like the cost of embedding Ops person into every team and that can create redundant work so they form a DevOps/SRE team. Good resource for different types of teams is here: https://web.devopstopologies.com/ https://web.devopstopologies.com/
  - deleted 2y ago
    [deleted]
- 0xbadcafebee 2y ago
  The reason you never encountered the second definition is two-fold: 1) There is no formal academic education behind the concept (that I'm aware of). If you do a CS major, nobody's going to explain to you the accumulated 15 years of practice and knowledge around the concept. 2) Due to 1), people just repeat what other people tell them. It's like a long game of telephone. It turns out most software development today is just a game of telephone between devs (and now AI). So almost everyone is misinformed. The Wikipedia page for DevOps is the best generic starting point if you want to know more. If you want to know more after that, there are a number of books and blog posts. Jez Humble, John Willis, Gene Kim, Patrick Debois, etc are the people to read. It's a much larger body of knowledge than you might think. Almost none of it has to do with devs supporting/running what they write (that's a small subset of a larger category, and there's multiple categories of 'stuff')
dilyevsky 2y ago
> You've got SREs who (mostly) write software, SREs who (mostly) stare at graphs and deal with random system failures, and now SREs who use a framework to develop a complex risk model of multiple systems (which is more quality control than engineering). This was always the case or at least going back 15 years or more highlighted by the so called “treynor curve”
- pmb 2y ago
  NB: The Treynor Curve is named after Ben Treynor and his ideas. Ben Treynor's name changed to Ben Sloss a few years back, and Ben Sloss is one of the authors of this article.
deleted 2y ago
[deleted]
01HNNWZ0MV43FF 2y ago
Never heard of dead-cat syndrome. In case anyone else wonders: > There is one thing that is absolutely certain about throwing a dead cat on the dining room table – and I don't mean that people will be outraged, alarmed, disgusted. That is true, but irrelevant. The key point, says my Australian friend, is that everyone will shout, "Jeez, mate, there’s a dead cat on the table!" In other words, they will be talking about the dead cat – the thing you want them to talk about – and they will not be talking about the issue that has been causing you so much grief https://en.wikipedia.org/wiki/Dead_cat_strategy https://en.wikipedia.org/wiki/Dead_cat_strategy
- johnkpaul 2y ago
  I actually don't think that's the dead-cat-saying that the parent is referencing. I think that it's this concept http://itskeptic.org/dead-cat-syndrome.html http://itskeptic.org/dead-cat-syndrome.html I am also unfamiliar though and I'm reading up on it right now.
  - 0xbadcafebee 2y ago
    That's the one. Only old fogies (like me) know it I guess. It was the thing we all referred to as the impetus behind DevOps, when it became a thing a decade ago.
    - dijksterhuis 2y ago
      i’m not an old fogie and i kind of guessed “throwing a dead cat over the wall” was what you meant. although i was actually taught DevOps proper before it got super fashionable. maybe that makes me an old fogie nowdays? :/
paulddraper 2y ago
> devs and sysadmins to talk about deploys together Not quite, it was the merger of development and operations responsibilities. I.e. devs who would sysadmin / sysadmins who would development.
zsoltkacsandi 2y ago
> a way for devs and sysadmins to talk about deploys together My take on this as someone who has 14 years of dev and 7 years of ops experience: DevOps is a flawed concept. The problem never was the lack of communication between the devs and sysadmins, it’s just a symptom. The root cause is that the management puts pressure on the devs to innovate and deliver as fast as possible, and puts pressure on the ops to ensure that the system is stable, reliable, scalable, it has a 99.95% uptime and any issues will be solved by the on-call. So these two groups have conflicting interests and when this leads to conflicts and arguments the conclusion is that they just don’t want to collaborate/communicate. There are many departments at a company that have conflicting interests and can interfere with each other. If DevOps was a real thing there would be a need for LegalOps, DevSales, DevProduct, HROps, etc..
- fragmede 2y ago
  Paralegals, legal clerks; sales engineers; product management, project management, TPMs; HR coordinator, HR administrative assistant... I'm not sure your examples say we don't need DevOps!
  - zsoltkacsandi 2y ago
    > Paralegals, legal clerks; sales engineers; product management, project management, TPMs; HR coordinator, HR administrative assistant The point wasn't that there are multiple job titles in different fields. > I'm not sure your examples say we don't need DevOps! The main assumption of DevOps is that the friction between developers and operations is the main cause of slow delivery. Well this friction can be happen between dev and legal, and dev and sales, and dev and product, and ops and product, and ops and sales, and ops and finance, etc. The companies that need DevOps have a much deeply rooted problem: the lack of collaboration between any department (not just dev and ops). Therefore DevOps won’t solve their problems. And companies that don’t have this problem won’t need DevOps, because they don’t have problems with collaboration.
- solatic 2y ago
  > DevOps is a flawed concept... conflicting interests... the conclusion is that they just don't want to collaborate/communicate. Wrong! This tendency is exactly what DevOps explains is the natural state of affairs without DevOps principles. The solution that DevOps advocates for is that such conflicting interests must not be expressed in meetings (where the culture conflict ensures they will get nowhere) but rather expressed in code. Infrastructure must be in code, deploys must be in code, testing must be in code, builds must be in code, policy must be in code, and the implicit pipeline with all the handoffs between teams connecting them all must also be in code. This makes everything fast (at least in comparison to manual processes), and makes everything explicit (in code) so that people can reach outside of their natural organizational silos to propose changes elsewhere in the pipeline, i.e. infra-focused engineers can add failing tests to prove the existence of a bug, developers can add infra that they need, QA can increase infra resources to ensure that sufficient resources are available for expected scale. The problem most organizations have is that they're not actually willing to force everyone's concerns to be written in code, and people are forbidden from reaching outside their silos. Usually this is due to poor hiring and training practice, e.g. "QA doesn't know how to write code" or "we can't let developers touch security policy". Sometimes it is due to leadership itself misunderstanding DevOps ("developers are forbidden from touching production"). > If DevOps was a real thing there would be a need for LegalOps, DevSales, DevProduct, HROps, etc. There is such a need, and it is generally being fulfilled by the systems in place. Small example - HROps would be ensuring that changes in the organization (i.e. people moving teams) accurately results in proper loss (of old) and gain (in new) privileges. This is done with integration between HR systems (the system of record as to who reports to whom and what their responsibilities are) and Active Directory or Google Workspace / Google Groups ensuring that people are automatically moved between the groups to which permissions are granted.

inquist 2y ago

I think failure mode analysis is definitely part of engineering

ImPostingOnHN 2y ago

Without resorting to any "big-D Devops" definition, I have almost always seen devops referring to "supporting / running the code you write", and have never encountered the definition where dev and ops were 2 different roles. That was what things were like before devops, and coordination on product support and planning wasn't great, hence devops.

moandcompany 2y ago
A lot of organizations simply renamed the functional area of "systems administration" or "systems engineering" to "DevOps," and at many of these places, "DevOps" is the new name for the group that software developers will throw stuff over the fence to. The issue with the above names is that they can be applied to a domain or area of practices, or an organizational boundary. In a non-trivial number of organizations, "DevOps" is viewed as a support entity for one or more software development teams, versus software development teams practicing "devops." This applies to many of the *_Ops names in fashion during the past five years or so.
- znpy 2y ago
  After almost 10 years in the systems engineering / administration / devops / cloud etc space all I can say is: The biggest improvement that devops brought is that it made managers feel dumb, outdated and scared because they were not "doing devops" while everybody else was, so they kinda started listening to sysadmins and what they had to tell. Uh, devops engineers did not come out of nowhere. They did not come out of the ground like mushrooms. Most if not all the "devops engineers" i know are just former sysadmins. They were already willing to do whatever devops was supposed to be, it's just they they were largely ignored. Writing this I just realized that maybe the best way to obtain organizational change is to make management and upper management feel stupid and outdated. Interesting.
  - steveBK123 2y ago
    Hence they have all hired “head of AI” in last 18 months.
    - moandcompany 2y ago
      "What is your AI strategy?" -> "We're hiring a Head of AI"
      - steveBK123 2y ago
        It’s the 2020s version of the old IBM line… No one ever got fired for hiring a head of AI.
stackskipton 2y ago
I'm Ops type person so I work at companies where there is a split between the two. Ops is a skill not all developers have or frankly, not even mindset to properly do so you will need a team/person to do it. Generally companies don't like the cost of embedding Ops person into every team and that can create redundant work so they form a DevOps/SRE team. Good resource for different types of teams is here: https://web.devopstopologies.com/ https://web.devopstopologies.com/
- deleted 2y ago
  [deleted]
0xbadcafebee 2y ago
The reason you never encountered the second definition is two-fold: 1) There is no formal academic education behind the concept (that I'm aware of). If you do a CS major, nobody's going to explain to you the accumulated 15 years of practice and knowledge around the concept. 2) Due to 1), people just repeat what other people tell them. It's like a long game of telephone. It turns out most software development today is just a game of telephone between devs (and now AI). So almost everyone is misinformed. The Wikipedia page for DevOps is the best generic starting point if you want to know more. If you want to know more after that, there are a number of books and blog posts. Jez Humble, John Willis, Gene Kim, Patrick Debois, etc are the people to read. It's a much larger body of knowledge than you might think. Almost none of it has to do with devs supporting/running what they write (that's a small subset of a larger category, and there's multiple categories of 'stuff')

dilyevsky 2y ago

> You've got SREs who (mostly) write software, SREs who (mostly) stare at graphs and deal with random system failures, and now SREs who use a framework to develop a complex risk model of multiple systems (which is more quality control than engineering). This was always the case or at least going back 15 years or more highlighted by the so called “treynor curve”

pmb 2y ago
NB: The Treynor Curve is named after Ben Treynor and his ideas. Ben Treynor's name changed to Ben Sloss a few years back, and Ben Sloss is one of the authors of this article.

deleted 2y ago

[deleted]

01HNNWZ0MV43FF 2y ago

Never heard of dead-cat syndrome. In case anyone else wonders: > There is one thing that is absolutely certain about throwing a dead cat on the dining room table – and I don't mean that people will be outraged, alarmed, disgusted. That is true, but irrelevant. The key point, says my Australian friend, is that everyone will shout, "Jeez, mate, there’s a dead cat on the table!" In other words, they will be talking about the dead cat – the thing you want them to talk about – and they will not be talking about the issue that has been causing you so much grief https://en.wikipedia.org/wiki/Dead_cat_strategy https://en.wikipedia.org/wiki/Dead_cat_strategy

johnkpaul 2y ago
I actually don't think that's the dead-cat-saying that the parent is referencing. I think that it's this concept http://itskeptic.org/dead-cat-syndrome.html http://itskeptic.org/dead-cat-syndrome.html I am also unfamiliar though and I'm reading up on it right now.
- 0xbadcafebee 2y ago
  That's the one. Only old fogies (like me) know it I guess. It was the thing we all referred to as the impetus behind DevOps, when it became a thing a decade ago.
  - dijksterhuis 2y ago
    i’m not an old fogie and i kind of guessed “throwing a dead cat over the wall” was what you meant. although i was actually taught DevOps proper before it got super fashionable. maybe that makes me an old fogie nowdays? :/

paulddraper 2y ago

> devs and sysadmins to talk about deploys together Not quite, it was the merger of development and operations responsibilities. I.e. devs who would sysadmin / sysadmins who would development.

zsoltkacsandi 2y ago

> a way for devs and sysadmins to talk about deploys together My take on this as someone who has 14 years of dev and 7 years of ops experience: DevOps is a flawed concept. The problem never was the lack of communication between the devs and sysadmins, it’s just a symptom. The root cause is that the management puts pressure on the devs to innovate and deliver as fast as possible, and puts pressure on the ops to ensure that the system is stable, reliable, scalable, it has a 99.95% uptime and any issues will be solved by the on-call. So these two groups have conflicting interests and when this leads to conflicts and arguments the conclusion is that they just don’t want to collaborate/communicate. There are many departments at a company that have conflicting interests and can interfere with each other. If DevOps was a real thing there would be a need for LegalOps, DevSales, DevProduct, HROps, etc..

fragmede 2y ago
Paralegals, legal clerks; sales engineers; product management, project management, TPMs; HR coordinator, HR administrative assistant... I'm not sure your examples say we don't need DevOps!
- zsoltkacsandi 2y ago
  > Paralegals, legal clerks; sales engineers; product management, project management, TPMs; HR coordinator, HR administrative assistant The point wasn't that there are multiple job titles in different fields. > I'm not sure your examples say we don't need DevOps! The main assumption of DevOps is that the friction between developers and operations is the main cause of slow delivery. Well this friction can be happen between dev and legal, and dev and sales, and dev and product, and ops and product, and ops and sales, and ops and finance, etc. The companies that need DevOps have a much deeply rooted problem: the lack of collaboration between any department (not just dev and ops). Therefore DevOps won’t solve their problems. And companies that don’t have this problem won’t need DevOps, because they don’t have problems with collaboration.
solatic 2y ago
> DevOps is a flawed concept... conflicting interests... the conclusion is that they just don't want to collaborate/communicate. Wrong! This tendency is exactly what DevOps explains is the natural state of affairs without DevOps principles. The solution that DevOps advocates for is that such conflicting interests must not be expressed in meetings (where the culture conflict ensures they will get nowhere) but rather expressed in code. Infrastructure must be in code, deploys must be in code, testing must be in code, builds must be in code, policy must be in code, and the implicit pipeline with all the handoffs between teams connecting them all must also be in code. This makes everything fast (at least in comparison to manual processes), and makes everything explicit (in code) so that people can reach outside of their natural organizational silos to propose changes elsewhere in the pipeline, i.e. infra-focused engineers can add failing tests to prove the existence of a bug, developers can add infra that they need, QA can increase infra resources to ensure that sufficient resources are available for expected scale. The problem most organizations have is that they're not actually willing to force everyone's concerns to be written in code, and people are forbidden from reaching outside their silos. Usually this is due to poor hiring and training practice, e.g. "QA doesn't know how to write code" or "we can't let developers touch security policy". Sometimes it is due to leadership itself misunderstanding DevOps ("developers are forbidden from touching production"). > If DevOps was a real thing there would be a need for LegalOps, DevSales, DevProduct, HROps, etc. There is such a need, and it is generally being fulfilled by the systems in place. Small example - HROps would be ensuring that changes in the organization (i.e. people moving teams) accurately results in proper loss (of old) and gain (in new) privileges. This is done with integration between HR systems (the system of record as to who reports to whom and what their responsibilities are) and Active Directory or Google Workspace / Google Groups ensuring that people are automatically moved between the groups to which permissions are granted.