4 ms·
That organizational/architecture benefit is strong though.
by rostos 3y ago
That organizational/architecture benefit is strong though.
- citrin_ru 3y agoIt’s depends on how you slice services. For one micro-service per a team I see benefits. On another end of the spectrum a single team managing 10-20 micro-services with more than one service per developer. IMHO it creates more problems than solves. Also it is usually a waste of HW resources because a library call it is cheaper then a network request.
- whstl 3y agoI think it depends on more than that. A single team managing 10 microservices that actually make sense to be microservices (like the PDF renderer example above [1]) is kinda good and perfectly manageable. A team with one single microservice that would actually work better if it was part of a monolith is already in the "creates more problems than it solves" territory. [1] https://news.ycombinator.com/item?id=35812294 https://news.ycombinator.com/item?id=35812294
- The_Colonel 3y agoI would frame it as a necessity rather than a benefit. Having siloed teams (services) is usually a problem which is better to avoid as much as you can.
- dtech 3y agoHaving autonomous teams is great for scaling and allowing everyone to go fast, without teams constantly blocking each other. Having hundreds of engineers work in a single monolith in a single repo without any kind of (enforced) boundaries is a one way ticket to a big ball of mud. You need to invest heavily in tooling to make it work, and e.g. Google does so. Having a network in between teams is a relatively easy way to enforce boundaries.
- The_Colonel 3y agoIt allows everyone to go fast as long as the work is constrained within one service. It goes very slow once service / team coordination needs to happen and one team alone is not able to deliver the feature. This then often leads to services duplicating logic, amassing responsibilities in order to do as much as possible within "my" service to avoid this coordination bottleneck.
- dtech 3y agoThen you're either not setting up your team responsibilities right, or you're not allowing cross-team contribution, both are fixable mistakes.