People argue for them from two different, drastically different, points of view:
* Microservices become necessary at some point because they allow you to independently scale different parts of the application depending on load.
* Microservices become necessary at some point because they allow you to create hard team boundaries to enforce code boundaries.
Personal opinion: micro services are always thrown out there as a solution to the second problem because it is easier to split a service out of a monolith than it is to put the genie of bad code boundaries back in the box.
An application goes through a few stages of growth:
1) When it starts, good boundaries are really hard to define because no-one knows what the application looks like. So whatever boundaries are defined are constantly violated because they were bad abstraction layers in the first place.
2) After a while, when the institutional knowledge is available to figure out what the boundaries are, it would require significant rewrites/refactoring to enforce them.
3) Since a rewrite/major refactor is necessary either way, everyone pushes to go to micro services because they are a good resume builder for leadership, and "we might need the ability to scale", or people think it will be easier ("we can splinter off this service!", ignoring the fact that they can splinter it off within the monolith without having to deal with networks and REST overhead).
Unfortunately, this means that everyone has this idea that micro services are necessary for code boundaries because so many teams with good code boundaries are using micro services.
Granular performance and team boundaries are both valid points. But, I haven't seen yet (around me) monolith applications so complex to have more teams working on them. I've seen instead applications developed by two persons where some higher-ups requested splitting them into microservices just because (no, scaling wasn't needed).
People argue for them from two different, drastically different, points of view:
* Microservices become necessary at some point because they allow you to independently scale different parts of the application depending on load.
* Microservices become necessary at some point because they allow you to create hard team boundaries to enforce code boundaries.
Personal opinion: micro services are always thrown out there as a solution to the second problem because it is easier to split a service out of a monolith than it is to put the genie of bad code boundaries back in the box.
An application goes through a few stages of growth:
1) When it starts, good boundaries are really hard to define because no-one knows what the application looks like. So whatever boundaries are defined are constantly violated because they were bad abstraction layers in the first place.
2) After a while, when the institutional knowledge is available to figure out what the boundaries are, it would require significant rewrites/refactoring to enforce them.
3) Since a rewrite/major refactor is necessary either way, everyone pushes to go to micro services because they are a good resume builder for leadership, and "we might need the ability to scale", or people think it will be easier ("we can splinter off this service!", ignoring the fact that they can splinter it off within the monolith without having to deal with networks and REST overhead).
Unfortunately, this means that everyone has this idea that micro services are necessary for code boundaries because so many teams with good code boundaries are using micro services.