5 ms·

This article triggers my Scrum™️ PTSD. The Way of DevOps? Am I going to have to fight off DevOps™️ certified consultants for the next five years now? By the

by cle 6y ago

This article triggers my Scrum™️ PTSD. The Way of DevOps? Am I going to have to fight off DevOps™️ certified consultants for the next five years now? By the way, I would recommend not trying to make your systems clever and “learn”, as the Third Way™️ suggests. Keep them dumb and understandable. The last thing a critical service needs is mysterious, unpredictable, unexplainable behavior. This point alone is a huge red flag for me, brace yourselves for five years of over-engineering as people blindly latch on to advice like this. I suppose this is the next round of silver bullets after “microservices”.

hn_throwaway_99 6y ago
It's an advertisement for a company's product on their corporate blog.
0xbadcafebee 6y ago
DevOps consultants have existed for years, but they only talk to upper management, like the Six Sigmas before them. This article doesn't really explain The Three Ways that well. I recommend going to the source: https://itrevolution.com/the-three-ways-principles-underpinning-devops/ https://itrevolution.com/the-three-ways-principles-underpinn... Keep in mind this is only one of several ways of explaining what DevOps is about, as the whole concept evolved over several years. Microservices were old and busted 5 years ago, but like Scrum, the industry pays no notice to broken patterns, only new ones. "Learning" is definitely a higher-order pattern that you have to practice to get good at. Whether it's machine learning, distributed tracing, sliding metric alarms, etc they aren't easy to implement correctly but they can level up the efficiency of dealing with big systems. You're right that simpler systems are best, until a specialized team can work on more complex ones without getting run into the ground.
TeeMassive 6y ago
> This article triggers my Scrum™️ PTSD. The Way of DevOps? Am I going to have to fight off DevOps™️ certified consultants for the next five years now? I feel you. Agile / DevOps certified consultants are an oxymoron. Outside of evangelization and some advice, they have no clue of the project and as such are just outsourced bosses. The core concepts are not that hard to grasp: teams are responsible to deliver value in small batches to the client so they can get quick feedback from the client. Having to employ them should be seen as a failure and as a symptom of a dysfunctional organization where the teams are not trusted by the higher ranks to have a say in how they organize themselves and thus they hire expansive people who gave them a sale pitch that corresponds initial vision. tl;dr: agile comes from within, people telling you how to work are just other way to say "boss". > By the way, I would recommend not trying to make your systems clever and “learn”, as the Third Way™️ suggests. Keep them dumb and understandable. The last thing a critical service needs is mysterious, unpredictable, unexplainable behavior. This point alone is a huge red flag for me, brace yourselves for five years of over-engineering as people blindly latch on to advice like this. If that happens the problem is not the people who try to develop improvements, it's the system that is not resilient to changes. These "mysterious, unpredictable, unexplainable" behaviors rarely manifest themselves all at once just by magic. They are usually caused by a comorbidity of problems that has accumulated due to a lack of will to fix them promptly or the lack of tools to catch and identify them early. Blaming your developers because they attempted to improve the system is just downright counterproductive and demoralizing because you will end up with a Tech Lead™️ playing police because they think they must protect the System like the Secret Services must protect VIPs from threats that could come up in all directions. Instead ask yourself those questions: How many times have you heard "we don't have time to fix this"? How many sheets of paper would you use to explain the multitasking architecture of your system? Can you test your system on a single thread so you can make sure your sequential logic is sound? How much time does it take to run all the tests? How much does your development environment differs from production? Can you easily toggle a feature to test it? The problem is not the "3rd way". There is a reason why they have numbered it from 1 to 3, it's because you can't achieve the third without the second and the first before that. In other words you can't learn acrobatics without learning how to walk first. > I suppose this is the next round of silver bullets after “microservices”. Fads are universally bad yes, but as with most prejudices they always have a kernel of truth.
- cle 6y ago
  I don't know what you're talking about WRT the 3rd way. I agree that developers should continuously improve their systems. I was replying to the descriptions in the article: > The third way of DevOps is continuous learning. [...] Sometimes this means introducing artificial intelligence and machine learning into your systems or tooling, to ensure that it is continuously learning. > The third way involves continuous learning. If our automated monitoring system, itself, can learn continuously from the traffic, access, and behavior of our cloud activity and users, then that respects the third way. A system that can train itself, learn when to remove permissions, when to replace permissions, and when to block access, not only respects the third way, it makes for a fantastic least privilege security tool. If your company specializes in this, and you have ML experts who know how to design, maintain, interpret, and monitor the models you are using in production, and who carry pagers so you can page them at 2 AM when something breaks and you can't understand what the model is doing...then sure. If you are the 99.999% of other companies, then this is a terrible idea and you should let me know before the interview so I can avoid working at your company (unless you're hiring me to remove it, because it inevitably caused more problems than it solved).
kesor 6y ago
Yes, its an invention by Gene Kim the author of The Phoenix Project and a couple of other books on the subject. Self profused expert in all things DevOps and inventor of the worst way to give names to common practices. First Way - is whatever practice, I never can remember. Second Way - is another practice, no idea which one. Third Way - is the third practice, naturally, equally eludes me.

by cle 6y ago

hn_throwaway_99 6y ago

It's an advertisement for a company's product on their corporate blog.

0xbadcafebee 6y ago

DevOps consultants have existed for years, but they only talk to upper management, like the Six Sigmas before them. This article doesn't really explain The Three Ways that well. I recommend going to the source: https://itrevolution.com/the-three-ways-principles-underpinning-devops/ https://itrevolution.com/the-three-ways-principles-underpinn... Keep in mind this is only one of several ways of explaining what DevOps is about, as the whole concept evolved over several years. Microservices were old and busted 5 years ago, but like Scrum, the industry pays no notice to broken patterns, only new ones. "Learning" is definitely a higher-order pattern that you have to practice to get good at. Whether it's machine learning, distributed tracing, sliding metric alarms, etc they aren't easy to implement correctly but they can level up the efficiency of dealing with big systems. You're right that simpler systems are best, until a specialized team can work on more complex ones without getting run into the ground.

TeeMassive 6y ago

> This article triggers my Scrum™️ PTSD. The Way of DevOps? Am I going to have to fight off DevOps™️ certified consultants for the next five years now? I feel you. Agile / DevOps certified consultants are an oxymoron. Outside of evangelization and some advice, they have no clue of the project and as such are just outsourced bosses. The core concepts are not that hard to grasp: teams are responsible to deliver value in small batches to the client so they can get quick feedback from the client. Having to employ them should be seen as a failure and as a symptom of a dysfunctional organization where the teams are not trusted by the higher ranks to have a say in how they organize themselves and thus they hire expansive people who gave them a sale pitch that corresponds initial vision. tl;dr: agile comes from within, people telling you how to work are just other way to say "boss". > By the way, I would recommend not trying to make your systems clever and “learn”, as the Third Way™️ suggests. Keep them dumb and understandable. The last thing a critical service needs is mysterious, unpredictable, unexplainable behavior. This point alone is a huge red flag for me, brace yourselves for five years of over-engineering as people blindly latch on to advice like this. If that happens the problem is not the people who try to develop improvements, it's the system that is not resilient to changes. These "mysterious, unpredictable, unexplainable" behaviors rarely manifest themselves all at once just by magic. They are usually caused by a comorbidity of problems that has accumulated due to a lack of will to fix them promptly or the lack of tools to catch and identify them early. Blaming your developers because they attempted to improve the system is just downright counterproductive and demoralizing because you will end up with a Tech Lead™️ playing police because they think they must protect the System like the Secret Services must protect VIPs from threats that could come up in all directions. Instead ask yourself those questions: How many times have you heard "we don't have time to fix this"? How many sheets of paper would you use to explain the multitasking architecture of your system? Can you test your system on a single thread so you can make sure your sequential logic is sound? How much time does it take to run all the tests? How much does your development environment differs from production? Can you easily toggle a feature to test it? The problem is not the "3rd way". There is a reason why they have numbered it from 1 to 3, it's because you can't achieve the third without the second and the first before that. In other words you can't learn acrobatics without learning how to walk first. > I suppose this is the next round of silver bullets after “microservices”. Fads are universally bad yes, but as with most prejudices they always have a kernel of truth.

cle 6y ago
I don't know what you're talking about WRT the 3rd way. I agree that developers should continuously improve their systems. I was replying to the descriptions in the article: > The third way of DevOps is continuous learning. [...] Sometimes this means introducing artificial intelligence and machine learning into your systems or tooling, to ensure that it is continuously learning. > The third way involves continuous learning. If our automated monitoring system, itself, can learn continuously from the traffic, access, and behavior of our cloud activity and users, then that respects the third way. A system that can train itself, learn when to remove permissions, when to replace permissions, and when to block access, not only respects the third way, it makes for a fantastic least privilege security tool. If your company specializes in this, and you have ML experts who know how to design, maintain, interpret, and monitor the models you are using in production, and who carry pagers so you can page them at 2 AM when something breaks and you can't understand what the model is doing...then sure. If you are the 99.999% of other companies, then this is a terrible idea and you should let me know before the interview so I can avoid working at your company (unless you're hiring me to remove it, because it inevitably caused more problems than it solved).

kesor 6y ago

Yes, its an invention by Gene Kim the author of The Phoenix Project and a couple of other books on the subject. Self profused expert in all things DevOps and inventor of the worst way to give names to common practices. First Way - is whatever practice, I never can remember. Second Way - is another practice, no idea which one. Third Way - is the third practice, naturally, equally eludes me.