I don't get how we can explain it in a simpler way? If you add a microservice, you're adding another point of failure. You add another interaction, you add more code. Add more code, you add more bugs.

It's pretty much the only empirical thing we have in software engineering, more code = more bugs.

Lots of little microservices means lots of extra code means lots of extra bugs.

Plus you've got to manage how they all interact. Which microservice has priotity? Did you even think of that? The breaking microservice? Or the volume microservice? Did you even think of that or try and test that? Your breaks get disabled every time you turn up the volume?

Whoops, you just killed a thousand people with your "redundant" microservices.

Erlang is build around the idea of microservices and message parsing. It's by far one of the best languages we have to make fail tolerant programs - it was invented to solve exactly that problem. While it does not mean you can take every program in any language and make them into a micro service architecture, it shows that if implemented correctly, the idea of microservices and messages absolutely increase reliability.

Do you object to redundancy under all circumstances, or only when it’s preceded by “microservice”?

If you add one microservice, you add a point if failure, but if you then add a few redundant copies of that microservice, for failover, then you don’t add a point of failure.

So… You're suggesting reducing the impact of potential error… By increasing the surface area of potential error…?!

It depends on the error. If its a logic error that will deterministically break all instances, then sure. If, on the other hand, its a transient error that a backup copy of the service can avoid, then redundancy adds safety. Sometimes safety critical software has multiple redundant units which need to agree, too, for example.