undefined | Better HN

0 pointsstaticassertion7y ago0 comments

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.

0 comments

SahAssar7y ago

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.

staticassertionOP7y ago

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.

squeaky-clean7y ago

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.

1 more reply

j / k navigate · click thread line to collapse