3 ms·

Not really. Even with a monolith, you get partial availability. Most often as a default. Imagine a web server handling requests. It usually has a way to recove

by krab 2y ago

Not really. Even with a monolith, you get partial availability. Most often as a default. Imagine a web server handling requests. It usually has a way to recover from a crashed request handler. On top of that, you have multiple web servers behind a load balancer. Some code paths may be failing, some may be available. Then, you have some background workers, maybe ingesting data from third party services. They're completely different processes from your web servers, even though they still use the monolithic code base. If they're down, the web app can still work with stale data. The partial availability can be compromised in microservices as well as in a monolith (e.g. auth as you mentioned).

lolinder 2y ago
> Imagine a web server handling requests. It usually has a way to recover from a crashed request handler. On top of that, you have multiple web servers behind a load balancer. Some code paths may be failing, some may be available. This is a form of partial availability but not what I'm talking about. I'm talking about a scenario where a DoS attack or an initialization error or an external service timing out causes the entire service (all instances) to fail to respond to any requests. Past a certain scale of app these things do happen periodically, and if you've split out non-critical code into separate services and handled for graceful degradation that code can no longer bring down the critical paths. > They're completely different processes from your web servers, even though they still use the monolithic code base. I... wouldn't call these part of a monolith, though they're not exactly microservices either. They're separately deployed units of code that happen to exist in a monorepo. This gives them similar resilience characteristics to microservices, so they're not a counterexample, they're more of a subcategory of what I'm talking about. > The partial availability can be compromised in microservices as well as in a monolith (e.g. auth as you mentioned). This is the "but sometimes" fallacy. If solution B allows for graceful degradation 80% more often than solution A, it's still better at graceful degradation even if it doesn't reach 100% success.

by krab 2y ago

lolinder 2y ago

> Imagine a web server handling requests. It usually has a way to recover from a crashed request handler. On top of that, you have multiple web servers behind a load balancer. Some code paths may be failing, some may be available. This is a form of partial availability but not what I'm talking about. I'm talking about a scenario where a DoS attack or an initialization error or an external service timing out causes the entire service (all instances) to fail to respond to any requests. Past a certain scale of app these things do happen periodically, and if you've split out non-critical code into separate services and handled for graceful degradation that code can no longer bring down the critical paths. > They're completely different processes from your web servers, even though they still use the monolithic code base. I... wouldn't call these part of a monolith, though they're not exactly microservices either. They're separately deployed units of code that happen to exist in a monorepo. This gives them similar resilience characteristics to microservices, so they're not a counterexample, they're more of a subcategory of what I'm talking about. > The partial availability can be compromised in microservices as well as in a monolith (e.g. auth as you mentioned). This is the "but sometimes" fallacy. If solution B allows for graceful degradation 80% more often than solution A, it's still better at graceful degradation even if it doesn't reach 100% success.