[p1necone]

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.

[jeremyjh]

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.

[lmm]

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]

    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]

> 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.

[cmeiklejohn]

This is the correct answer. Microservices are a software engineering optimization from the socio-technical perspective primarily. 100%.

[cmeiklejohn]

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.)

[ilyt]

> 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]

> 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.