Cloud provider's best trick was to convince everyone that network calls are better than function calls.
Not really. Cloud providers did convince everyone that if you hit a resource limit in one of your boxes then your best strategy is being able to add more boxes, and not move everything and the kitchen sink to a larger box.
Also, not everything sits in the hot path of anything. Sometimes all you want is a long-running job to run somewhere.
* Network calls are traceable by default — logging all incoming queries is easy, logging all function calls is harder.
* Network calls are easily made — function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language, while network calls can be done with nothing more than curl/grpcurl/etc.
The downsides are a) decreased performance b) you have to handle failures c) dev ergonomics, but eh. I would still choose network calls over function calls for a big backend, probably.
It's really not though. Many (most?) languages have some way to annotate function calls with logging logic
function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language
Completely disagree if you work on low latency systems, or a high volumes of requests: functions are traceable if you need to in a crisis: plug a profiler, run like prod, see the hot paths.
Dev ergonomics explode the cost of everything and you spend your time trying to figure out what the hell is going on where rather than just... plugging the profiler and sending the input, then observe the internals moving around.
If the system can work without micro services, it should.
Network calls are easily made — function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language, while network calls can be done with nothing more than curl/grpcurl/etc.
Define "easy" because curl is not "easy" compared to a function call and involves building a few large datastructures to work at all.
I think this is a blanket statement on my part, so to counter it; networked databases are definitely important. Some micro services maybe necessary for things outside of your control (HIPAA, Finance audits) and geo-proximity processing needs. And sometimes good ol micro services became popular because it was easy business in a giant org chart (Amazon, every team has an API).
Comments
Cloud provider's best trick was to convince everyone that network calls are better than function calls.
Not really. Cloud providers did convince everyone that if you hit a resource limit in one of your boxes then your best strategy is being able to add more boxes, and not move everything and the kitchen sink to a larger box.
Also, not everything sits in the hot path of anything. Sometimes all you want is a long-running job to run somewhere.
I think they are, though. Off the top of my head:
* Network calls are traceable by default — logging all incoming queries is easy, logging all function calls is harder.
* Network calls are easily made — function calls in a backend can require passing some kind of a huge config structure, or might be entirely unavailable if you're using a compiled language, while network calls can be done with nothing more than curl/grpcurl/etc.
The downsides are a) decreased performance b) you have to handle failures c) dev ergonomics, but eh. I would still choose network calls over function calls for a big backend, probably.
It's really not though. Many (most?) languages have some way to annotate function calls with logging logic
Not really sure what you're referring to here
Oof. Everything in my 12-13 years of engineering has led me to the exact opposite conclusion of literally every point you made here.
Are you genuinely suggesting that making a network call is easier than calling a function in the same code base running in the same process?
Completely disagree if you work on low latency systems, or a high volumes of requests: functions are traceable if you need to in a crisis: plug a profiler, run like prod, see the hot paths.
Dev ergonomics explode the cost of everything and you spend your time trying to figure out what the hell is going on where rather than just... plugging the profiler and sending the input, then observe the internals moving around.
If the system can work without micro services, it should.
Define "easy" because curl is not "easy" compared to a function call and involves building a few large datastructures to work at all.
I think this is a blanket statement on my part, so to counter it; networked databases are definitely important. Some micro services maybe necessary for things outside of your control (HIPAA, Finance audits) and geo-proximity processing needs. And sometimes good ol micro services became popular because it was easy business in a giant org chart (Amazon, every team has an API).
Real world is messy.
I’m not anti micro services. I’m anti micro services as a code organization strategy.
There are very real reasons to need process isolation in larger systems. Code modularity is not one of them.