3 ms·
Sure, but not all micro-services are vital. If your "email report" service has a memory leak (or many other noisy-neighbor issues) and is in a crash loop then t
by therealdrag0 4y ago
Sure, but not all micro-services are vital. If your "email report" service has a memory leak (or many other noisy-neighbor issues) and is in a crash loop then that wont take down the "search service" or the "auth service", etc. Many other user paths will remain active and usable. It compartmentalizes risk.
- whiplash451 4y agoProper design in a monolith would also protect you from failures of non-vital services (e.g. through exception capture). So it seems like we’re trying to compensate bad design with microservices. It’s orthogonal IMO.
- therealdrag0 4y agoHow does exception capture protect from all failures? The most obvious one I don't see it relating to is resource utilization, CPU, memory, threadpools, db connection pools, etc etc. > we’re trying to compensate bad design No I think we're trying to compensate for developer mistakes and naivety. When you have dozens to hundreds of devs working on an application many of them are juniors and all of them are human and impactful mistakes happen. Just catching the right exceptions and handling them the right way does not protect against devs not catching the right exceptions and not handling them the right way, but microservices does. Maybe you call that compensating for bad design, which is fair and in that case yes it is! And that compensation helps a large team move faster without perfecting design on every change.
- JAlexoid 4y agoWith microservices you have to have a tradeoff - a monolith is inherently more testable at integration level, than a microservice based architecture. There's a significant overhead to build and run tests at API level, that includes API versioning... and there's less of a need to version API inside a monolith.