[safetytrick]

An under-rated solution to this problem is saying No and having quality retrospectives.

Microservices adoption has largely become a cargo cult thing. It is a part of being cool like FAANG.

Instead of being cool, focus on solving your problems.

[tdeck]

Microservices are a solution to an organizational challenge: how do we set clear boundaries of ownership within a complex system? From a technical perspective there are pros and cons.

Unfortunately, I don't see a wealth of other ready-made practices for companies to copy when they grow and need to solve this problem. I once worked on an enormous Rails monolith that was very well organized and had layered on several additional patterns to improve modularity and maintainability. Still, a SEV in a minor product area could (and did) bring down the whole system, and they were in the process of dismantling it.

[drewcoo]

Actually, loosely-coupled microservices improve testability, too. And improve it by far if we're comparing with monoliths (where tight coupling is considered a "feature").

One of the troubling practices is tightly-coupled containerized services, though, which only gives us all of the problems of microservices at the same time as we have all of the problems of monoliths.

[sisve]

A microservice architecture is a good way to solve the problem with the monolith. The problem is the word mikro. It should have a better name. If it was called "boundary architecture" or similar it would make people stop creating to small pieces. One team should not manage 15 services.

[willsmith72]

> Instead of being cool, focus on solving your problems.

This needs repeating to every dev every week. Myself included