[api]

One of the benefits of being in this industry for a while is that you learn to spot and avoid fads. You even learn classes of fads.

Microservices instantly looked like a fad. Two classes of fad apply. One is a "move stuff around and complexity will magically go away" fallacy fad. The other is a "way to promote vendor lock-in or higher cost" fad.

Other major classes of fads are: consultant self promotion fads, re-invention fads of all kinds in which devs speed run the history of some aspect of computing to arrive at the same place, magic pixie dust fads where sprinkling some buzzword on things makes everything better, management "methodology" panacea fads, etc.

Avoiding fads is a superpower. It tends to save a whole lot of money and wasted time.

The test of whether something is a fad is whether it reduces incidental complexity, enables something categorically new, or genuinely boosts developer velocity.

Incidental complexity is the complexity that creeps into our designs that is not essential to the problem but an artifact of how we got there or some prior limitation in how things are done. A genuine innovation will make incidental complexity actually go away, but not by pretending that essential complexity doesn't exist.

A categorically new thing would be e.g. deep learning or an actually practical and useful provably-safe language (Rust).

Boosting developer velocity means actually speeding up time to ship without doing so by adding a ton of technical debt or making the product suck.

If something doesn't do at least one of those things well, it's a fad.

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

[msaspence]

> "move stuff around and complexity will magically go away" fallacy

This is a great description of microservices

[anonymoushn]

> actually practical and useful provably-safe language (Rust).

You can have spatial and temporal memory safety by writing single threaded code in any GC language.