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)
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.
No they don't. There's no reason why two different teams can't schedule an upgrade of the same service at different times. The riskiness of this is entirely dependent upon how good your integration test suite is.
>if a module update introduces a performance bug, it will affect everything else.
The module will still affect everything that is dependent upon it if it is rebuilt as a microservice. You're just moving the performance problem from one place to another.
>if you want to update a core lib for component X, it will need to be updated (and tested) for everything else.
Ok, so upgrade the library and run the full set of integration tests.