Microservices also enforce boundaries significantly more strongly. A layered monolith can still easily have random people cut across boundaries without you knowing because there are hundreds of engineers all working in the same system.
Large companies don't have problems throwing more engineers at a problem. But they will always have a problem in coordination costs.
Microservices also allow you to use different tech stacks for different purposes more easily.
Maybe use java for one involving hadoop or some GIS library. Use erlang for some message management service, use golang for some simple API service, use nodejs for some frontend web server, etc.
Overall the advantages of microservices come for social reasons, not for a particular technical reason.
Layered systems do not have to be 'monolithical'. Note that we're both at this moment using layered systems to have this conversation.
> A layered monolith can still easily have random people cut across boundaries without you knowing because there are hundreds of engineers all working in the same system.
I appreciated your final word regarding "social reasons" and I think we're in strong agreement in that regard.
In the final analysis, it seems accurate to say that Microservices approach permits runtime operational [micro] payments towards organizational and analytical debt [1].
The hypothetical system(/straw man?:) you posit above is indicative of organizational, not architectural, failure/deficiency.
Large companies don't have problems throwing more engineers at a problem. But they will always have a problem in coordination costs.
Microservices also allow you to use different tech stacks for different purposes more easily.
Maybe use java for one involving hadoop or some GIS library. Use erlang for some message management service, use golang for some simple API service, use nodejs for some frontend web server, etc.
Overall the advantages of microservices come for social reasons, not for a particular technical reason.