Dividing areas amongst teams is only a theoretical benefit if you haven't solved the factoring problem. Otherwise teams are still going to be cross-dependent on other teams constantly.

But if you've solved the factoring problem, your team and another team can happily work next to each other in the same codebase with less back-and-forth anyway. And the question reduces largely to if you deploy it all at once or not. Sometimes all at once is much easier anyway.

I've seen microservices used by management as a way to force engineering into factoring their shit correctly far more often than I've seen it done because things were already factored well (because cross-team coordination in different services is much harder than just jumping around in the monolith's single repo in a single PR). It's an easy lever for management to pull, too, because most devs don't see it as something they're being forced to do, they think they're getting their wish at rewriting and modernizing things. ;)

> factoring their shit correctly

When is shit ever factored "correctly"? Next week, your product owner will come over with a new idea for a feature spanning multiple modules and suddenly you will realize you should have factored your shit differently and maybe not split things up into multiple microservices prematurely.

So what I'm trying to say is: Grug is right. Factoring a piece of software correctly is one of the hardest issues. The assumption that you can do it correctly is the reason why so many microservice architectures are such a PITA to work with.

It’s true that factoring is something you can spend an unbounded amount of effort on, but it’s too unwieldy to always say factored “so well that there is no point working more on it because of diminishing returns”. So when you see “correctly”, read that as “so well that there is no point working more on it because of diminishing returns”.

Arguably that is what correct factoring is anyway, because it’s simply not correct in any way to fiddle with a piece of software without generating any real value for either the business objectives or the developers that have to work with it down the road.

I don't understand how this isn't mitigated by a CODEOWNERS file[0]. Give the directories to the teams that should own them, and now they have absolute control over the PR review process accordingly (and responsibility of incoming code for the directories that they own too).

[0] https://docs.github.com/en/repositories/managing-your-reposi...

That just solves one problem, and not the most significant. Other issues, not usually inherent to the monolith pattern but very common:

* Release management coupling

* CI coupling

* Deployment coupling

* Binary bloat

* Monitoring/alerting/logging noise

* Lack of security policy granularity

* Language and library choice coupling

Of course, people mess these things up with the service model as well, but the failure modes there don't propagate as much (unless they're organizationally mandated...)

… which often turns everything into siloes not talking to each other, using different languages/tools/processes/release plans. No thanks.

The world is not so black and white, and silos have legitimate business purposes. The reality is that any one contributor or team can only handle so much. When duties must be split between teams for effective ownership of responsibilities, separation of concerns becomes paramount to the continued progress in any one domain.

If all you have is one team, microservices make no sense.