[cirego]

I've noticed that there's another problem with microservices as well. People tend to tie microservices and multi-repo into the same strategy.

Multi-repo appears to make teams faster (builds are faster! fewer merge conflicts!) but, like micro-services, they push complexity into the ether. Things like updating service contracts, library updates, etc. all become more complicated.

[jayd16]

I think the real sin is just cutting against the grain on your services and library boundaries.

It's not that hard to version and deploy multiple services and libraries. If you need the flexibility of that separation, it can very much be worth it.

But if you separate them and still treat them like you're in a mono whatever and you cut corners on keeping your separation clean and clear, you're going to have a bad time.

Either pattern has its advantages. It's best to remember that they're just a pattern and you should be doing one or the other for a reason.

[taeric]

Oddly, I would say that this often exposes complexity? Not that that is a valid reason to go all in on it. But some things, like updating service contracts, are complicated. Indeed, anything that makes it look like many services all deployed in unison is almost certainly hiding one hell of a failure case.

[kerblang]

In my experience, while monorepo makes shared libraries between services easier, that inevitably turns into "Hey, why not just put a copy of my application inside yours?"

[twic]

Having gone from multi-repo to monorepo recently, I'd say the opposite. A multi-repo lets you do those things incrementally. A monorepo forces you to do them in one go.