It also depends on what kind of monolith we're talking about.<p>We've found that "moduliths" (modular monoliths split into clearly defined bounded contexts with public APIs) work as well as microservices for scaling development: each team is responsible for their own module, there are very few conflicts, there's no spaghetti because we have architectural reviews whenever a module wishes to cross the "module barrier" and call into another module etc. (i.e. introducing a new dependency). You can spin up as many modulith instances as you wish as well.<p>The problem is that our modulith is written in PHP using a very popular enterprisey framework. PHP is based on the paradigm of spinning up a new process per request (php-fpm can recycle them but still), so every request ends up reinitializing the whole framework every time: its entire dependency injection tree. Every new module increases response times linearly, it doesn't scale. Another issue is that the single DB (common for monoliths) becomes the bottleneck, as all modules/contexts go through it.<p>Our PHP modulith is very costly in terms of runtime. A similar request into a microservice is usually 20-50 times faster because it's written in Go and manages its own DB. I think if our monolith was written in Go or Java from the very beginning we would have less impressive results after switching to microservices. Stuff rewritten from scratch is also usually faster than tons of old accumulated cruft.<p>Deployment/compilation is much faster now, the old monolith also used to have a lot of JS/CSS processing, PHP linters during build etc. so a tiny change to a module would trigger full recompilation of all modules running for 30-40 minutes. Each microservice is a separate deployment however, so a change to it only takes 1-2 minutes to deploy/release.<p>My point is that when people are talking about monoliths vs microservices they are often comparing dinosaurs written 10-15 years ago (PHP, old frameworks with bad design decisions, tons of accumulated spaghetti) to modern, more lightweight languages/tooling (for example, Go, k8s etc)<p>I think a "modern modulith" has its right to exist and is a viable competitor to microservices, provided they use more lightweight frameworks/tools, use paradigms such as modules and CQRS, and if somehow they allow smart, incremental deployments.