[majormajor]

> But, what distributing some of the components into so-called microservices would give you is a graceful failure scenario where even if all the instances of a specific component fail, the rest of the application still works. Maybe only one function stops working temporarily but most work continues on.

The important thing to note here is that microservices give you one way to build a graceful failure scenario. You don't get it for free. Often that 500 will propagate all the way back! So you have all the same failure modes + network failure modes!

You could also build a monolith that could handle component level failures, for that matter. Tooling doesn't seem to be as common, though.

[snupples]

I don't disagree with you at all. There are certainly different ways of thoughtfully building things.

The point being you don't need to be a paying subscriber to microservices(tm) to recognize there can be positives to the approach, which you describe in your last paragraph

A monolith that can handle component level failures is very close to the same idea infrastructure-wise minus a lot of baggage implied by the buzzword microservices.

[FpUser]

"A monolith that can handle component level failures" - being able to handle component level failures I think is more related to business logic design rather than being a monolith/microservice implementation. If your business process depends on some login microservice and that one is down it does not matter that the other parts are functional.

[snupples]

So just to play to your hypothetical. If there were two login methods, and they were separate microservices, if only one failed and the other remained up, that would be the graceful failure scenario.

I'm not telling you that you must to do this. Others may have requirements that go beyond yours.