4 ms·
Note the relationship between the size of the team and the ability to manage a monolith. A team that grows larger quickly needs some way to manage the complexi
by afarrell 5y ago
Note the relationship between the size of the team and the ability to manage a monolith.
A team that grows larger quickly needs some way to manage the complexity within the codebase and the difficulty of knowing whom to talk to. In theory, it is possible to build a modular monolith with clear ownership boundaries. In practice, this requires strong technical leadership.
- papito 5y agoKelsey Hightower, a core Kubernetes engineer, once said that microservices were created because teams didn't want to talk to each other. One problem - they still have to talk to each other.
- afarrell 5y agoIts a question of how much they need to talk together. My current company has a code base which, if we want to avoid falling into technical bankruptcy, teams will need to spend 35 hours per week talking to other teams. The goal of well-defined interfaces is to reduce that to 2-5 hours per week. Saying “microservices” is a concise yet oversimplified way to describe what is actually needed: well-defined modules with clearly-visible boundaries.
- dominotw 5y ago> Kelsey Hightower, a core Kubernetes engineer, Not sure what you mean by 'core' but my impression was that he was more of an evangelist and a community manager.
- papito 5y agoMy understanding of his role is vague, but my point is more that, even as an "evangelist" of K8S, he is not going to suggest that you use it because Google does.
- pjc50 5y agoYup, papito is absolutely correct; microservices are just Conway's law. They're not for scaling the software, they're for scaling the organisation.
- afarrell 5y agoWhich is why I wish there was a meaningful term like “pizza-sized services” as a way to say “these don’t need to be tiny, but they do need to be small enough that a 4-8 person team can handle the mental load of managing them.”