> You let teams within a business organize as if they were separate businesses and let them offer services to each other as if they were operating different businesses.
> This is done in large organizations to ensure that developers aren't forever bogged down in meetings. If you have 10,000 developers all trying to work on the same project the communication overhead will kill you. Microservices is a way to try to overcome that.
Microservices do work better in large organisations, but I don't think the boundary should be defined by teams, because large orgs perform re-orgs more often than you'd expect.
It really should be defined by product. When a company is reorganised, then you'd be passing around products and product groups and not individual microservices, to the new teams.
I'm not sure a team is defined by individuals who may come and go. Look at professional sports teams that have been around for a long time. None of the people involved in the team today are the same people who were there in the beginning. The people don't define the team.
I expect you will find that service, product, and team all mean approximately the same thing in this context.
> This is done in large organizations to ensure that developers aren't forever bogged down in meetings. If you have 10,000 developers all trying to work on the same project the communication overhead will kill you. Microservices is a way to try to overcome that.
Microservices do work better in large organisations, but I don't think the boundary should be defined by teams, because large orgs perform re-orgs more often than you'd expect.
It really should be defined by product. When a company is reorganised, then you'd be passing around products and product groups and not individual microservices, to the new teams.