[trixie_]

There’s a huge difference between http and function calls. When I call a function there is no chance it fails because the function ‘cannot be reached’. With services there are endless reasons why one service is unable to communicate with another. It’s a huge amount of overhead to build a system to handle inter-service communication and failure that doesn’t exist when only calling a function in the same binary.

[biglost]

And, you add latency issues and overhead. With a function call you pass two int and get a string of length 120 (how much memory is this? little, very little), with microservices you make an api call using http with it headers and get a json, and maybe you could need 2 api calls. For me it's easy, just create a monolith, when you become facebook or netflix, split symfony services into microservices (just an example). Oh, and don't forget the developers who translate a specific function into an endpoint, you need a change in the caller and you must change the api!

[FinanceAnon]

I agree, but perhaps I didn't word it the right way in my original comment. With microservices there is a big overhead in development and managing failures, but functionally it doesn't offer much more than a function call within a monolith.

[com2kid]

> When I call a function there is no chance it fails because the function ‘cannot be reached’.

Run time DI configured from XML.

With enough Java anything is possible!

[helge9210]

> When I call a function there is no chance it fails

I like to print statements like this one and put them in a frame on the wall.

[trixie_]

Fails because the function is unreachable. The second half of the sentence you quoted says exactly that, why did you cut it out?

[helge9210]

If execution of your binary is stopped some time between the call and return (with following restart), dealing with it is no simpler than dealing with network partitioning.

[valenterry]

It is. Because then you know that the caller also must have failed. Whereas with an http call, you might want to retry, log the error, fall back to a cache, etc. etc.

[mellinoe]

This is ignoring the fundamentally-different issue that was raised, which is that the service boundary introduces a new failure point that doesn't exist in a function call. What you're describing could just as easily happen in a service call, IN ADDITION to the service just not being reachable.

[zo1]

It most certainly is easier to deal with the in-process version. I'm specifically referring to database transactions, which are much harder to have available in a distributed context. That failed network call complicates your life so much.