3 ms·
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
by mattmanser 7y ago
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.
- hvidgaard 7y agoErlang 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.
- dkersten 7y agoIf 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.
- asfarley 7y agoDo you object to redundancy under all circumstances, or only when it’s preceded by “microservice”?