A lot of factors come together whenever the term Microservie or Monolith arises:
- Monolith has implicitly replaced the word "Legacy" system
- Microservices were (/are still) the cool thing to do in a conference driven industry. They were championed by big tech because they desire granular and flexible deployment systems (whereas in smaller products your code just needs to run and everything else is just overhead). Having multiple instances of a MS can fix some performance issues as well.
- People rarely talk about failing with their new (microservice) projects.
- Microservices can be a technical solutions for human problems. Large teams benefit from distributed deployments due to organizational reasons. They also force you to think more about modelling your responsibilities, which might be add odds with your company culture.
To me, Microservices are not an architecture pattern but a deployment strategy. Obviously, you want high cohesion and modules, which you might or might not get with Microservices. It comes down to understanding your problem domain.
If you have a modular monolith, you can still deploy it separately at a later point if the need arises. Even having a shared database is not a problem if your modules are only using the respective tables they own (this can be enforced with permissions).
- Monolith has implicitly replaced the word "Legacy" system
- Microservices were (/are still) the cool thing to do in a conference driven industry. They were championed by big tech because they desire granular and flexible deployment systems (whereas in smaller products your code just needs to run and everything else is just overhead). Having multiple instances of a MS can fix some performance issues as well.
- People rarely talk about failing with their new (microservice) projects.
- Microservices can be a technical solutions for human problems. Large teams benefit from distributed deployments due to organizational reasons. They also force you to think more about modelling your responsibilities, which might be add odds with your company culture.
To me, Microservices are not an architecture pattern but a deployment strategy. Obviously, you want high cohesion and modules, which you might or might not get with Microservices. It comes down to understanding your problem domain.
If you have a modular monolith, you can still deploy it separately at a later point if the need arises. Even having a shared database is not a problem if your modules are only using the respective tables they own (this can be enforced with permissions).