If you have to use 'Chaos Engineering' to experiment your way into innovation, this is a sign you built your service wrong. What will Amazon Re-Invent next!? I am guess the wheel. Well written article though.
If you have to use 'Chaos Engineering' to experiment your way into innovation, this is a sign you built your service wrong. What will Amazon Re-Invent next!? I am guess the wheel. Well written article though.
However, it won't necessarily help you know how your system will behave if S3 kicks the bucket in us-east-1 (again), your image host for that super-cool Kubernetes cluster suddenly throttles you during a critical restart, or your other service of choice went down due to an expired certificate.
If you however mean to use it to perform a denial of service on an endpoint you don't own, you're more hard-core than I thought.
With you so far
> A bash script utilizing curl will suffice.
Lol hell no. Yes, AWS/amazon does require a "GameDay" before launching a service which will execute an mcm (managed change management) that's basically a runbook of (way more in depth and comprehensive way to test your service than a single bash script with curl), but chaos engineering is a great additive, additional verification mechanism that really helps with service outages.
How are you going to test a thundering herd with a bash script executing curl?
How many machines are you running this simple bash+curl script on anyway? Using a single node to generate requests isn't going to do much in testing a service's reliability.
Also, they literally did invent a wheel
How does a bash script simulate network failures, connectivity drops or a gray-failure in one of your dependencies? [2]
A lot of thought has been put into this domain. Dismissing that without understanding any of the complexities is just showing your ignorance.
[1] - https://brooker.co.za/blog/2023/05/10/open-closed.html
[2] - https://docs.aws.amazon.com/fis/latest/userguide/fis-actions...