Towards Modern Development of Cloud Applications (2023)

This looks like it parallels the shift from MapReduce's paradigm of one binary per execution graph node to FlumeJava (and Apache Beam's) monolithic binary for all worker nodes that reconfigures itself as necessary for each stage. My experience is that Flume/Beam is a lot nicer in almost all ways, so I'm not surprised that the same thing works for services too.

I think that this might actually be something new - you have the same topology as a microservice architecture, but rather than actually programming and deploying one binary per microservice, you build a single binary with all of the functionality and it gets deployed as a fleet of microservices, running a different subset of all of that functionality depending on what it's deployed as. Which means you have only one build and one deploy step and atomic deploys, like a monolith, but you also get to scale each component independently and isolate data like with microservices. A really nice looking middle ground.

I've used this paradigm for a long time. What's new here ?

Basically your code has no concept of "network boundary", there's only package import each other, there's no "microservice".

But when deploying, i can choose which package to be deployed as a service.

So shipping two applications that use the same authentication service is a mistake?