[neo01124]

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.

[fxtentacle]

I did understand what the article is about. But you only need to worry about failure under stress if you are driving your system close to the hardware's limit.

In the virtual cloud world, that is common, because you rent the cheapest instance that will be big enough. In the bare metal world, that is rarely the case, because you usually get a Ryzen with 16+ cores and 128+ GB of RAM. In that case, there's no point in checking what will happen to your 200 MB web app if there's a CPU spike. It'll be just fine because the hardware can handle 10x the load without a hickup.

Similarly, if your page load time is dominated by internet latency, it doesn't matter if your CPU needs a few more ms to spit out the page HTML. So there, a 2x CPU usage increase will be barely noticeable to the user.