2 ms·
> The second most common bad reason is because business units don't want to talk to one another. This sounds like a terribly naive take. It matters nothing if
by rewmie 3y ago
> The second most common bad reason is because business units don't want to talk to one another.
This sounds like a terribly naive take.
It matters nothing if units talk to one another. Nothing. All it matters is ownership and accountability. What happens if the service managed by team A goes down and takes the whole org with it? Is team B going to take the blame because one of their developers posted a PR to tweak the project's README?
- MBCook 3y agoIt’s real. I’ve seen it. They can’t get their internal silos to work together on a single project, so they have each silo make services for the others to use in service of the project they’re trying to make that needs multiple teams. But… all the same problems come up. Teams building to their requirements and not what the consumers need, refusal to cooperate in design/requirements/etc, scheduling issues or project priority issues. “Microservices are cool and what Google does and will help us avoid our organizational issues” is very loosely paraphrased from what I heard as the exact pitch for why it was being used.