4 ms·

Ah. The great recoupling. Soon someone will find a way to keep it in the same process.

by jddj 3y ago

jayd16 3y ago
Hmm, it's transparent data that's passed to the callee. Are you saying it's more coupling because it's not explicit in the gRPC schema?
- quietbritishjim 3y ago
  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.
menzoic 3y ago
Coupling to context?
p1necone 3y ago
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.
- cmeiklejohn 3y ago
  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.)
- jeremyjh 3y ago
  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.
  - cmeiklejohn 3y ago
    This is the correct answer. Microservices are a software engineering optimization from the socio-technical perspective primarily. 100%.
  - lmm 3y ago
    It would be nice to be able to make rigid and well-defined boundaries without having to add the overhead of serialization and network boundaries.
    - kitd 3y ago
      public interface MyWellDefinedBoundary { ... } ;) Edit: I should say this is what OSGi was good for. Now it's been replaced, its need is greater than ever.
    - bheadmaster 3y ago
      > well-defined boundaries without having to add the overhead of serialization and network boundaries Type systems and APIs do that, but only within a single language.
- ilyt 3y ago
  > 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.
  - cmeiklejohn 3y ago
    > Think that's called Erlang. No, it's not. 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.

Ah. The great recoupling. Soon someone will find a way to keep it in the same process.

by jddj 3y ago

Ah. The great recoupling. Soon someone will find a way to keep it in the same process.

Hmm, it's transparent data that's passed to the callee. Are you saying it's more coupling because it's not explicit in the gRPC schema?

quietbritishjim 3y ago
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.

menzoic 3y ago

Coupling to context?

p1necone 3y ago

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.

cmeiklejohn 3y ago
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.)
jeremyjh 3y ago
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.
- cmeiklejohn 3y ago
  This is the correct answer. Microservices are a software engineering optimization from the socio-technical perspective primarily. 100%.
- lmm 3y ago
  It would be nice to be able to make rigid and well-defined boundaries without having to add the overhead of serialization and network boundaries.
  - kitd 3y ago
    public interface MyWellDefinedBoundary { ... } ;) Edit: I should say this is what OSGi was good for. Now it's been replaced, its need is greater than ever.
  - bheadmaster 3y ago
    > well-defined boundaries without having to add the overhead of serialization and network boundaries Type systems and APIs do that, but only within a single language.
ilyt 3y ago
> 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.
- cmeiklejohn 3y ago
  > Think that's called Erlang. No, it's not. 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.