[whstl]

Different sections of an app can use different databases, if the bottleneck is in the database.

Different routes can be served by different servers, if the bottleneck is in CPU usage.

Different async tasks can run on different task runner services, if the problem is tasks competing with each other.

Different test suites can run for different sections of the app, if the problem is with tests taking too long to run.

Github and others even allow specific subfolders to be "owned" by different teams.

What else is there? Even slowness of compilation and/or initialization can be alleviated, depending on the language or framework.

[stronglikedan]

I think the point is that all of that adds complexity that is often unnecessary - a premature optimization if you will. It's like a hammer, and everything looks like a nail to a lot of people.

[inopinatus]

GP isn’t oppositional, they listed runtime constructs that all run off a single monolith. The point being you don’t need so-called microservices for flexibility in the production environment.

[whstl]

As the sibling poster said, you probably misunderstood my point.

I'm talking about how monoliths can also fix such problems when they happen.

[the_sleaze_]

Old incompatible library versions; dependency hell, security SLAs. Old company couldn't get off of Rails 3 for a multitude of reasons and splitting off microservices was a good decision. Syncing state across the services turned into its own barrel of monkeys, but was better overall.