[Kalium]

I agree that microservices shift complexity, but I'm not sure that this inherently results in an overall increase in complexity. For example, using highly automated ops tools like autoscaling and load balancing can enable smooth handling of problems that can be challenging to handle in code.

[candiddevmike]

Instead of shuffling data between things via shared memory/function args, you're doing it over the network. This will always be more complicated.

[QuercusMax]

Here at Google, one of our most popular microservices frameworks enables microservices to be assembled into servers. If one microservice calls another one in the same assembly, it won't touch the network, and is quite optimized. There's no reason that microservices have to all run in separate binaries, but when it's useful it can be done easily enough without having to change your code.

[wussboy]

I find my self doing the opposite. I’ll often create a Cloud Task that will call the same server that created it, just to make sure that another container will get spun up to handle the load if needed. Using Cloud Run this way quite happily for a mix of OLAP and OTAP workloads.

[throwaway2037]

Is the framework open source? And what language(s)? It sounds interesting!

[QuercusMax]

Not open source; I've only used the java version, but there's support for c++ and go as well.

[Kalium]

Yes, it shifts communication to over the network, but this comes with the benefit of making system boundaries much clearer. It's been my experience that this can allow different parts to evolve separately and make the choices best for their own needs, which can sometimes result in a paradoxical reduction of complexity as one all-in-one system turns into a series of simpler tools. Suddenly the part of the system that does background ETL work and the part of the system that serves up the admin panel can use different tools.

I will agree that networks are inherently complicated, but your system or systems probably use networks anyway. Using them internally often forces you to grapple with the complexity you were already facing. Plus, it's been my experience that networks are easier for most to reason about than shared memory and mutexes.

Let's not forget providing an easy set of dials to turn to scale a given part of the system. That's a point of complexity, but it can be an immensely useful one. Complexity is not always the enemy - a power drill is more complex than a manual screwdriver and this complexity is pretty useful.

[candiddevmike]

Given the trade off of synchronous vs asynchronous, I hope most folks try their damnedest to use the former before having to use the latter.