Exactly that. The beauty of gRPC (and similar) is that you can look at the schema and know exactly what the necessary inputs and outputs are. With this addition, you no longer have any idea.
What if you have a nested stack of calls where microservice A calls microservice B which calls ... etc. Then you're looking at the schema of microservice F, and even the source code where it's called in microservice E, and can't figure out how to you can call it to get it to do the same thing. Little do you know, you need to set some things up that currently only A knows how to do.
Imo microservices should be a logical boundary only. Whether they're in the same process/server/cluster etc ideally should be purely based on throughput/latency/scale concerns. Even more ideally the services should be dynamically shuffled around hosts based on load at runtime.
Microservices are only used to scale engineering teams, not software. You can have a monolith that is still deployed in many different capacities or roles to get any optimization benefits. Microservices are needed because large groups aren't good at working together on software without very rigid and well-defined boundaries.
Academics have tried to make this a reality for years. I suggest revisiting Waldo's "A Note on Distributed Computing" and working forwards from there. If you want to go back further, look at Argus, Emerald, and the original Hermes (from DEC.)
> Whether they're in the same process/server/cluster etc ideally should be purely based on throughput/latency/scale concerns. Even more ideally the services should be dynamically shuffled around hosts based on load at runtime.
Think that's called Erlang.
> Imo microservices should be a logical boundary only.
Having option to split it freely is a costly abstraction to deal with, especially if it is cross-language.
I prefer to just leave "cutting lines" in monolith. Well defined modules and relations between them so if some feature needs to be spun off it's not too hard.
As someone who programmed Erlang both professionally and published academically at Erlang venues for a long time, no.
These optimizations "for runtime" are not well supported by Erlang (i.e., cluster performance changes dramatically when behavioral characteristics of message passing switch from local to remote to remote cluster very quickly) and were long discussed in Waldo's paper back in the 90s, dynamic relocation is not supported well (i.e., unless you use global, which falls apart quickly under network anomalies, of which I, and several others, wrote paper(s) about), and the runtime hardly provides any information on introspection on cluster performance.
Sadly, distributed Erlang had the edge on programming distributed systems almost 20 years before they became pervasive, but has since been left to atrophy and hasn't seen any real innovation in quite a long time.