Theoretically, microservices allow for each team to deploy independently, thus the choice is made up front, before any part of the system is designed, because it looks like it reduces the effects of inter-team communication lag.
i.e. Docker lets you better push the org chart into production.
It makes figuring out that the boundaries of responsibility in your app/org are poorly defined harder to address.
The biggest place I ever worked, I came to believe that their chaos worked because it was self organizing. They’d split a large project into parts, and the groups that didn’t work well would find the boundaries of their mandate constantly eroded by their more capable neighbors upstream and downstream from them. Eventually all the gaps would fill in, which is why the company worked. But it meant many orgs and applications did work that would have made more sense to be done at a different step in the process, if not for incompetence/bandwidth. Things would happen here or there not because of some waterfall design but because of where the task was in the development flow and who had more bandwidth at the time.
They kept a lot of old guys around not because they were effective but because they were historians. They knew where the bodies were buried, and who was the right person to ask (not just which team but who was helpful on that team). We had a greybeard who basically did nothing but was nice to be around and any time you had a problem he knew who to introduce you to.
> When writing a distributed application, conventional wisdom says to split your application into separate services that can be rolled out independently. This approach is well-intentioned, but a microservices-based architecture like this often backfires, introducing challenges that counteract the benefits the architecture tries to achieve. Fundamentally, this is because microservices conflate logical boundaries (how code is written) with physical boundaries (how code is deployed).
What usually happens is the the same team ends up owning 5 microservices that all have weird interdependencies with leaky abstractions, shared code, and unwritten interface contracts between them.
Theoretically, microservices allow for each team to deploy independently, thus the choice is made up front, before any part of the system is designed, because it looks like it reduces the effects of inter-team communication lag.
i.e. Docker lets you better push the org chart into production.