Re:How we ended up with microservices
by crdoconnor on Friday September 11, 2015 @12:36AM
(#10202038)
>Monolith: Bring down the service completely.
Unless you've scaled your "monolith" horizontally, in which case it takes out one server.
If you've got a decent system, it can self heal from that and ping you via a monitoring system.
>Microservices/SOA: Timeouts to part of the system
Causing all manner of annoying behavior and difficult to track down bugs like an endlessly loading web page on a completely different system that happens a couple times a week instead of a clear error message.
>Assuming you've done a decent job of engineering for partial failure
If you assume a fantastic job done when engineering then you can make the worst architectural patterns "work". It doesn't mean that they are good ieda.
There's absolutely no reason why you can't timeout within your monolith.
Re:How we ended up with microservices
by tomchristie on Thursday September 10, 2015 @02:52PM
(#10199847)
Indeed. But you can't guard against catastrophic system failures (out of memory, disk, processor time, corruptions) in the way you can with independant services.
Your services are running on different servers (or containers) to each other, so they're partitioned. If one service has a bug that introduces a catastrophic error that takes all the server resources you'll either:
Monolith: Bring down the service completely. Microservices/SOA: Timeouts to part of the system, and partial loss of functionality.
(Assuming you've done a decent job of engineering for partial failure)