I don't see how. Your points of failure were always there, but at most they're more explicit since "service failure" conflates with "network failure" - something I think is beneficial, since you always had to handle "service failures" but they were implicit.
That is - a piece of code in a monolith may fail, and a piece of code in a microservice may fail, but I've already written the code to handle network errors for the microservice case, which means I've also implicitly handled the "bug in code" case.
That assumes that a local function call has the same failure rate as a remote function call to a microservice, which in my experience is very much not true.
If I have a local function in the same language I can pretty much assume that a call to that function will actually call that function. With a remote call over HTTP or whatever I can't, so that is an additional failure I need to handle.
I'm not sure I understand. Why would an RPC call a different function than what you expect?
I'll grant you that there is more complexity in this approach, but I believe that fault tolerance is something you improve with microservices, not something you regress on.
It's not that it would call a different function, but that sometimes the RPC will fail to call the function. You can't get a network error calling a function which is in memory on the same process.
Yes, you have to handle the failure case of "network call". Microservices add this failure case. But you already had to handle the case of "code blew up because of a bug".
By forcing you to handle comm errors like network failure, you also force people, implicitly, to handle "code blew up because of a bug" errors. Even though it adds a second error case, you pretty much handle them the same way in the same place.
There was always an error case - the fact that code may blow up.
>But you already had to handle the case of "code blew up because of a bug".
I'm handling bugs very differently than network failures though, because network failures are usually temporary while bugs are usually (or even by definition) permanent.
Dealing with temporary outages in lots of places is extremely difficult. You may need retry logic. You may need temporary storage or queuing. You may need compensating transactions. You may need very carefully managed restarts to avoid DDOSing the service once it comes back online. There may be indirect, non-deterministic knock-on effects you can't even test for properly.
Microservices cause huge complexity that is very hard to justify in my opinion.
That is - a piece of code in a monolith may fail, and a piece of code in a microservice may fail, but I've already written the code to handle network errors for the microservice case, which means I've also implicitly handled the "bug in code" case.