[Mavvie]

> different parts of the monolith's functionality need to scale independently,

I hear this a lot. Can you give me an example? Can't I just add more pods and the "parts" that need more will now have more?

Agreed on the other reasons (although ideally the entire monolith should be CI/CD so release cadence is irrelevant, but life isn't perfect)

[jimbokun]

So the alternative is to have a monolith deployed with different "identities" based on how it's configured. So you configure and scale out different groups of the monolith code independently, to satisfy different roles and scale up or down as needed.

However, sometimes the resources needed to load at start up can be drastically different, leading to different memory requirements. Or different libraries that could conflict and can also impact disk and memory requirements. For a large monolith, this can be significant.

So at what point do you go from different "configuration", to where enough has changed it's a truly different service? The dividing line between code and configuration can be very fluid.

> the entire monolith should be CI/CD so release cadence is irrelevant

But if one module has a bug and is failing testing, or features partially completed, it blocks releasing all the other code in the monolith that is working.

[treis]

>For a large monolith, this can be significant.

If we are at this point we aren't really talking about microservices though. More like taking a gigantic monolith and breaking it up into a handful of macroservices.