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.
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.
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.