[tomtheelder]

Microservices are very much not a fad, and they aren't even that new of a concept. They have just gotten more attention recently, and have probably been over-adopted a little bit.

In the right circumstances, a microservices architecture can absolutely boost developer velocity. You can reduce development/mental model complexity, reduce blocking internal dependencies, increase performance of tooling and deployment, and allow more consistent and less risky deployments. There are certainly costs: infrastructural complexity, a new network boundary between services, increased risk of techincal/product drift.

For orgs where the benefits outweigh the costs, due to scale/org structure/perf concerns/etc it can be an enormous win for velocity. For other orgs it can be a huge velocity killer. It just depends.

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

[jnash]

Everything you claim is unproven and pure speculation. However what is proven to be true is that thousands of developers all over the world can effectively work on massive monoliths (like Linux and Windows) without using microservices.