neo01124

That is more about the "engineering" bit.

The article does talks about how to inject latency or packet-loss into calls to particular external services. This should help you test many service->dependency failure scenarios around retries, timeouts and circuit-breakers.

Injecting specific error codes or exceptions is a bit more complicated but it is possible with other approaches, for example: Chaos toolkit.

No, there is no different approach. You are misunderstanding what is being addressed in the article. This is not about bare metal vs cloud or autoscaling vs no-autoscaling/overscaling or developer time vs resource costs.

The article talks about injecting failures at various points in the system, understanding how the system behaves under this stress, putting in counter-measures for the resulting problems, and eventually re-running this to validate those counter-measures.

Stress testing a whole app ecosystem end-end and preventing/mitigating end user impact is generally a part of "gamedays" - https://wa.aws.amazon.com/wat.concept.gameday.en.html.

A library like AWSSSMChaosRunner would be a core component of building gameday like capability. But building a full gameday framework is out of the scope of this discussion.

Author of the article here.

Please take a look at the underlying library here (AWSSSMChaosRunner) - https://github.com/amzn/awsssmchaosrunner

Hi!

Author of the article here.

The core concern is not about the capabilities of the compute abstraction being used (bare metal, containers or functions) or testing OS capabilities. The aim is to validate mitigations which are in place to counter turbulent scenarios (For example: massive spike in traffic, network outage, dependency is down, etc). These scenarios generally originate outside the given system.

These kind of questions should be asked and systematically validated (quoting the article):

* Have you tested how the system behaves when the underlying instances have a sustained CPU spike?

* Is the system behavior understood under different stress?

* Is there sufficient monitoring?

* Have the alarms been validated?

* Are there any countermeasures implemented? For example, is auto-scaling set up, and does it behave as expected? Are timeouts and retries appropriate?

Hi! Author of the article here.

The AWSSMChaosRunner approach can't be used for Lambda because of what @vasco said.

You can take a look at a different approach here for failure injection in Lambda - https://medium.com/@adhorn/failure-injection-gain-confidence...