I feel all these black and white comparisons of monolith vs microservices tend towards being overly reductive and miss the crux of the matter.<p>First, "microservice" is a terrible name (we should have just stuck with SOA), it leads to all kinds of agile consultant snake-oil salesmen claiming some ideal size for a service. That's bullshit. Services should be defined by their interfaces, full stop. If you can't come up with a stable interface between two services such that the interface changes orders of magnitude than the code within each service, or if you find yourselves always having to deploy the services in pairs due to leaky abstraction on the interface, <i>then they probably shouldn't be two services</i>.<p>Second, SOA is primarily a tool for scaling teams. Yes there are some tangential benefits in terms of code base size, CI build time, etc, but those are false economies if you have a small team that has to deal with the overhead of many services.
Modern web-scale architectures are really about factoring things to leverage specialists to scale very large tech platforms.<p>Third, and perhaps most importantly. In any rapidly growing business you need to evolve quickly. You should not expect to design a perfect architecture day one, you should plan to evolve the architecture continuously, so that every two orders of magnitude growth you look up and realize you've replaced most of what you've previously written one way or another. Small startups that focus on "microservices" before they are anywhere near 100 engineers tend to die before traction.