This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? In theory the extra work of making an API call would give you smaller bowls of spaghetti. However, once you add some abstraction to making these calls it seems like developers are empowered to make the same mess. Except now it is slower and harder to debug.
simplotek|3 years ago
It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen.
Walls make great neighbors, just like multiple services make teams great at complying with an architecture constraint.
thunky|3 years ago
I think you're trying to solve a communication problem with a technical solution, which is a recipe for trouble.
If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better. Especially once you inevitably realize that you put the walls in the wrong place and functionality has to move across borders, which is now a major pain because you've intentionally made it hard to change.
eeperson|3 years ago
I'm not sure I follow this. Doesn't this just mean that it is harder to make changes? Why would it be harder to make bad changes and not harder to make good changes?
> Walls make great neighbors, just like multiple services make teams great at complying with an architecture constraint.
I'm not sure I follow this either. Why would multiple services make teams great at complying with an architecture constraint?