Chaos Engineering seems most useful in the context of distributed systems though, and I'm not entirely certain how you would implement it outside of that context.

I would consider applying invalid inputs, etc. to non-distributed systems to be more along the lines of traditional testing. Perhaps you could implement chaos engineering principles in a non-distributed system by simulating the failure of a CPU core or a region of memory? It seems less useful though, as those things seem very difficult to effectively recover from.

How would you define "chaos engineering" to apply to non-distributed systems?

> Perhaps you could implement chaos engineering principles in a non-distributed system by simulating the failure of a CPU core or a region of memory?

Could be. In a general sense of chaos engineering.

For me, I think chaos engineering would be to keep generating "chaos" in a system or module or any unit. Chaos in this sense would be to break it, or any kind of maltreatment to it.

I agree with Arcsech in that Chaos Engineering is most useful in the context of distributed systems. However, this doesn't mean that you can't learn something new from experimenting in, say, a local VM.

As a matter of fact, Netflix is running a big distributed system, so that's where they focus their testing efforts. In general, I think it's fair to talk about Chaos Engineering and systems in the general sense, distributed or not.