[api]

The same advantages can be achieved by separating things into libraries or discrete packages.

Microservices just takes that and spreads it around a K8S cluster using gRPC or RESTful JSON or some other RPC bus for all the various modules to talk to each other, consuming far more compute resources and helping increase atmospheric CO2 and make cloud vendors rich. Why is calling a library running in a separate task (possibly on a separate CPU) via gRPC a better approach to code modularity?

The only time this makes sense is when you are (1) totally huge and (2) have specific hot regions of your service that you want to autoscale relative to the rest of the service.

Incremental upgrades can be achieved by just incrementally cycling your service, no microservices needed. Doing so when only some modules change can be achieved with CI without the crazy runtime overhead.

[tomtheelder]

I agree that it only really makes sense to consider when you have runtime concerns around performance that justify the added complexity. I posted that in a comment elsewhere. However, I think the benefit to modularity can be significant sometimes. Separating something into libraries is an exercise in organizational discipline, and in my experience it often fails. An inviolable boundary can be valuable for orgs who struggle with that sort of thing.

That said, even small apps virtually always have hot regions. Typically those can be ignored until big scale without impacting the users, but that doesn't mean it's efficient to do so.

I would also definitely push back on the idea that a monolith is inherently more compute/energy efficient. I'm not sure how you arrived at that conclusion, but it doesn't take much in the way of efficiency gained from individually scaling services to make up for the tiny additional costs of your orchestration/communication.

Personally I'm a monolith guy. I think the discipline required to build and release a good monolith is typically easier than the difficulty of maintaining services. I would rarely recommend a microservice architecture. But I don't think it's in anyone's best interests to just pretend that the benefits of microservices don't exist.