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. ;)
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.
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.
[0] https://docs.github.com/en/repositories/managing-your-reposi...
* 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...)
If all you have is one team, microservices make no sense.
Is it something to do with calculating the cost of splitting off a monolith into a microservice vs. some other method?
This is a hard problem that spans architectures; you can have a poorly factored microservice architecture, just as you can have a poorly factored monolith.
These two posts from Shopify are good:
https://shopify.engineering/deconstructing-monolith-designin...
Maybe one exception is if you absolutely must change the programming language at the same time, but even then I would suggest doing the rewrite as a monolith first for the same reason, so you again don't have to deal with network calls at the same time as solving an already insanely hard problem.
There's the argument that microservices lets you gradually replace the old monolith piece by piece, but there's nothing special about microservices for that, you can do that with two monoliths and a reverse proxy.
And at the end of either you might find that you didn't need microservices in the first place, you just needed to factor the application better.