I recently had some discussions and did some research on this topic and I feel like there is a lot people don't talk about in these articles.
Here are some more considerations between micro services and monolothic tradeoffs. Its also important to consider these two things as a scale and not a binary decision.
1. Isolation. Failure in on service doesn't fail the whole system. Smaller services have better isolation.
2. Capacity management. Its easier to estimate the resource usage of a smaller service because it has less responsibilities. This can result in efficiency gains. Extended to this is you can also give optimized resources to specific services. A prediction service can use GPU while web server can use CPU only. A monolothic may need to use compute with both which could result in less optimized resources.
3. Dev Ops Overhead. In general monolothic services have less management overhead because you only need to manage/deploy one or few services over many.
4. Authorization/Permissions. Smaller services can be given a smaller scope permissions.
5. Locality. Monolothic can share memory and therefore have better data locality. Small services use networks and have higher overhead.
6. Ownership. Smaller services can have more granular ownership. Its easier to transfer ownership.
7. Iteration. Smaller services can move independently of one another and can release at seperate cadences.
I work on low code cloud ETL tools. We provide the flexibility for the customer to do stupid things. This means we have extremely high variance in resource utilization.
An on demand button press can start a processes that runs for multiple days, and this is expected. A job can do 100k API requests or read/transform/write millions of records from a database, this is also expected. Out of memory errors happen often and are expected. It's not our bad code, its the customer's bad code.
Since jobs are run as microservices on isolated machines, this is all fine. A customer(or multiple at once) can set up something badly, run out of resources, and fail or go really slow and nobody is effected but them.
Its not automatic but it has the potential for more isolation by definition.
If your service has memory leak, crash it only takes down the service. It is still up to your system to handle such a failure gracefully. If such a service is a critical dependency then your system fails. But if it is not then your service can still partially function.
If your monolith has memory leak, or crash it takes down the whole monolith.
But not all sequences. It depends on your dependencies. Some services are critical for some processes. In the monoloth design its a critical dependency for all processes.
Here are some more considerations between micro services and monolothic tradeoffs. Its also important to consider these two things as a scale and not a binary decision.
1. Isolation. Failure in on service doesn't fail the whole system. Smaller services have better isolation.
2. Capacity management. Its easier to estimate the resource usage of a smaller service because it has less responsibilities. This can result in efficiency gains. Extended to this is you can also give optimized resources to specific services. A prediction service can use GPU while web server can use CPU only. A monolothic may need to use compute with both which could result in less optimized resources.
3. Dev Ops Overhead. In general monolothic services have less management overhead because you only need to manage/deploy one or few services over many.
4. Authorization/Permissions. Smaller services can be given a smaller scope permissions.
5. Locality. Monolothic can share memory and therefore have better data locality. Small services use networks and have higher overhead.
6. Ownership. Smaller services can have more granular ownership. Its easier to transfer ownership.
7. Iteration. Smaller services can move independently of one another and can release at seperate cadences.