4 ms·

Is this a case of "netflix did those articles, so we'll do the same so geeks like us too"?

scarmig 6y ago
If nothing else, the article showcases how to use the recently released AWSSSMChaosRunner[0], which I hadn't heard about. Beyond that, it's good when multiple different high quality blog posts show how to do what's fundamentally the same thing. [0] https://github.com/amzn/awsssmchaosrunner https://github.com/amzn/awsssmchaosrunner
danellis 6y ago
It does seem like a fad. Kudos to those who can create a new field and profit from it. On the one hand, "chaos engineering" seem a bit like "we don't understand our architecture well enough to know what its failure modes are, so let's just poke it and see what happens," but on the other hand, it seems at least a little bit analogous to fuzzing, which is certainly a technique that yields useful results that would have otherwise been overlooked until it was too late.
- kokooo 6y ago
  There are a million different ways a computer can fail. I think we're asking too much of people to be able to know all the pitfalls of every system they create. But also this 'new field' just seems like something we've already been doing just with a different name. You're kind of expected to make sure your system can work if the computer suddenly shuts off, or a dependency is lost, or the network is slow. Have we not been doing this??
  - danellis 6y ago
    It does seem antithetical to engineering, though. Are there other engineering fields that take this approach?
- eru 6y ago
  > On the one hand, "chaos engineering" seem a bit like "we don't understand our architecture well enough to know what its failure modes are, [...] That approach seems like a good idea, even if you think you know what the failure modes are.
- mohave529 6y ago
  My first instinct was to agree with this, but from my experience it's extremely difficult to properly communicate failure modes 100% of the time across different teams in very large organizations. Dependencies that are fuzzy arise for example when a service A proxies data for client service B from some other service C. It doesn't help that the organization of teams in a company often severs lines of communication between teams who explicitly don't have dependencies but implicitly do. As a result, information gets lost in the process. Having a last line of defense in the form of a "chaos engineering" team may actually be the natural response of large organizations to counter the inherent messiness that is produced as a result of bureaucracy.
  - lhoff 6y ago
    That and additionally it has implications for the development team as well. Using "chaos engineering" shifts the mindset of the developers. As a developer you now expect things to fail. You know that the "we make it work first and make it resilient later" approach will bite you sooner then later so you think resilience from the first line of code.
- twblalock 6y ago
  You don't know what all your failure modes are. You probably think you do, but you don't. That's the point of chaos testing.
cheeze 6y ago
My guess? Someones manager was like "Hey lets publish this wiki as a blog post." Sure, part of it is trying to seem cool and whatnot, but that's fine with me. The output is the same, more knowledge shared.
marmshallow 6y ago
Definitely seems like a case of someone that wanted to publish a blog post for some internal kudos, but I'm not complaining. Always good to share knowledge.
- smabie 6y ago
  It sounds like complaining to me
jwilber 6y ago
Never thought I’d see anti-article sentiment on HN, and more generally, not sure what sort of response you expect to generate. Why comment at all? To avoid more of the same, I’ll say that the article itself is pretty detailed, but whereas Netflix blog-posts are more general, this one feels hyper-specific. That’s great if you’re tied to aws, but I think the former has longer-lasting + further-reaching utility. Hope they do more.
- BiteCode_dev 6y ago
  Not an anti-article sentiment, but I dislike the trend of big companies pretending they care about the nerds just because they realize they need them for one particular objective. It's an anti-marketing sentiment.
  - jwilber 6y ago
    That makes more sense. I think it’s worth framing differently, though. Big companies aren’t writing the doc, per se. Engineers interested in the material are. And often, they want the opportunity to do so - it’s something of a stamp for “expertise” in their favor. Assuming the post is actual quality, it’s a marketing win for the company, a professional/developmental win for the employee, and an informational win for everyone else.

If nothing else, the article showcases how to use the recently released AWSSSMChaosRunner[0], which I hadn't heard about. Beyond that, it's good when multiple different high quality blog posts show how to do what's fundamentally the same thing. [0] https://github.com/amzn/awsssmchaosrunner https://github.com/amzn/awsssmchaosrunner

danellis 6y ago

It does seem like a fad. Kudos to those who can create a new field and profit from it. On the one hand, "chaos engineering" seem a bit like "we don't understand our architecture well enough to know what its failure modes are, so let's just poke it and see what happens," but on the other hand, it seems at least a little bit analogous to fuzzing, which is certainly a technique that yields useful results that would have otherwise been overlooked until it was too late.

kokooo 6y ago
There are a million different ways a computer can fail. I think we're asking too much of people to be able to know all the pitfalls of every system they create. But also this 'new field' just seems like something we've already been doing just with a different name. You're kind of expected to make sure your system can work if the computer suddenly shuts off, or a dependency is lost, or the network is slow. Have we not been doing this??
- danellis 6y ago
  It does seem antithetical to engineering, though. Are there other engineering fields that take this approach?
eru 6y ago
> On the one hand, "chaos engineering" seem a bit like "we don't understand our architecture well enough to know what its failure modes are, [...] That approach seems like a good idea, even if you think you know what the failure modes are.
mohave529 6y ago
My first instinct was to agree with this, but from my experience it's extremely difficult to properly communicate failure modes 100% of the time across different teams in very large organizations. Dependencies that are fuzzy arise for example when a service A proxies data for client service B from some other service C. It doesn't help that the organization of teams in a company often severs lines of communication between teams who explicitly don't have dependencies but implicitly do. As a result, information gets lost in the process. Having a last line of defense in the form of a "chaos engineering" team may actually be the natural response of large organizations to counter the inherent messiness that is produced as a result of bureaucracy.
- lhoff 6y ago
  That and additionally it has implications for the development team as well. Using "chaos engineering" shifts the mindset of the developers. As a developer you now expect things to fail. You know that the "we make it work first and make it resilient later" approach will bite you sooner then later so you think resilience from the first line of code.
twblalock 6y ago
You don't know what all your failure modes are. You probably think you do, but you don't. That's the point of chaos testing.

cheeze 6y ago

My guess? Someones manager was like "Hey lets publish this wiki as a blog post." Sure, part of it is trying to seem cool and whatnot, but that's fine with me. The output is the same, more knowledge shared.

marmshallow 6y ago

Definitely seems like a case of someone that wanted to publish a blog post for some internal kudos, but I'm not complaining. Always good to share knowledge.

smabie 6y ago
It sounds like complaining to me

jwilber 6y ago

Never thought I’d see anti-article sentiment on HN, and more generally, not sure what sort of response you expect to generate. Why comment at all? To avoid more of the same, I’ll say that the article itself is pretty detailed, but whereas Netflix blog-posts are more general, this one feels hyper-specific. That’s great if you’re tied to aws, but I think the former has longer-lasting + further-reaching utility. Hope they do more.

BiteCode_dev 6y ago
Not an anti-article sentiment, but I dislike the trend of big companies pretending they care about the nerds just because they realize they need them for one particular objective. It's an anti-marketing sentiment.
- jwilber 6y ago
  That makes more sense. I think it’s worth framing differently, though. Big companies aren’t writing the doc, per se. Engineers interested in the material are. And often, they want the opportunity to do so - it’s something of a stamp for “expertise” in their favor. Assuming the post is actual quality, it’s a marketing win for the company, a professional/developmental win for the employee, and an informational win for everyone else.