> when you have a very large number of employees developing software it means that you can keep your teams out of each others' hair
Two things here. One is that it often looks like the tail wagging the dog. Microservices are often introduced to manage and support development teams that grew too large. Unfortunately the correct course of action in such cases is layoffs not microservices.
Two. In my experience the places I worked at where microservices were extensively used had even more issues of employees stepping on each other as compatibility issues and upgrade sequence between services were a frequent concern and the independent testing was a total myth as most teams did not provide good mocks for their API surfaces. Meanwhile troubleshooting such distributed systems was _very_ real and very hard.
Agreed on the first if the company was hiring armies of juniors, which isn't going to work either way.
As for the second: yes, you can mess it up, a solution like that requires both discipline and someone in charge of architecture with the power to enforce the rules. If everybody runs off to create their own little kingdom and APIs then it's just going to make matters worse. Sometimes much worse.
But here is an idea: if you run a typical web company you already have a couple of ways in which you can slice up your monolith:
The hot path, all that which is visible to the unwashed masses and the internal software that your various employees use to deal with order flow, support requests and so on (assuming that you built those rather than bought them, as you probably should have).
The part that is visible to everybody on the web can in turn be split up into content delivery, pages that are visible to non-logged in users and pages that are visible to users. Possibly you have a mobile phone application. Maybe your back-end has certain features that can be easily parted out and made to operate stand alone. Before long you'll have somewhere between 5 and 10 cleanly separated chunks, each of which can be worked on in isolation because the only thing all these have in common is the persistence layer, which can serve as a single source of truth. Everything else can be made as stateless as possible.
Such a solution would serve the vast bulk of the e-commerce and SPA solutions out there and would scale to very large size without breaking a sweat. Then, if it becomes necessary to break things up further this should be done with the realization that those parts will need to continue to function as a whole and that architecture will have to take a front seat if it is to work at all, which means the company will have to hire a capable systems architect who can balance the extra complexity with the flexibility required. This is not a trivial thing to do and messing it up will come with a hefty price tag.
Two things here. One is that it often looks like the tail wagging the dog. Microservices are often introduced to manage and support development teams that grew too large. Unfortunately the correct course of action in such cases is layoffs not microservices.
Two. In my experience the places I worked at where microservices were extensively used had even more issues of employees stepping on each other as compatibility issues and upgrade sequence between services were a frequent concern and the independent testing was a total myth as most teams did not provide good mocks for their API surfaces. Meanwhile troubleshooting such distributed systems was _very_ real and very hard.