Hacker News Reader

Comment by viraptor | Hacker News Reader

> "we have 100 people so require 20 microservices"

Is this something that actually happened? Not heard from some third party - actually has someone experienced this as a decision in a technical team? It seems... unlikely.

View on HN

It's usually a consequence of something like Bezos' API mandate https://api-university.com/blog/the-api-mandate/

Multi-team ownership of a single deployable has downsides to tradeoff against the complexity of more service and harder boundaries.

That doesn't translate from the mandate, which is what I'm trying to cautiously call out. There's a big difference between "our company will not have a god database" and "we need to make more services just because we have more people". The link also mentions that the mandate was "something long these lines" - we don't know exactly what the split rules were.

I think people bring up an exaggerated idea of extreme microservices being forced on people when it rarely if ever happens. If not, I'm happy to hear actual first hand experiences.

It does if there's an upper bound on the number of people in an effective team.

It's not "there's an extra person, now we need to create a new service". It's more likely "we need this extra service and that means some people will need to take care of it". It's an inverse of what the comment I'm disputing said.

Anyways, it's still not an example of this happening. It's a recollection of a letter that maybe implies this result.

This is an application of Conway's law. If we want small five-person teams then there are 20 teams and it makes sense to simplify communication by decomposing the system into 20 parts.

(Not saying it's the right way to do things, just the natural way to optimise if you need to keep 20 teams busy working on one system. I think the incorrect assumption is that all 20 teams need to be busy doing the same thing.)

Decomposing the system into libraries is just as effective from this perspective as decomposing into services however. The thing that a typical http API gives you is stability (documentation, versioning and a deprecation policy). This can be done with a library as well. We know this works as 3rd party libraries work well and no communication with the authors of the library is needed.

This is why I suggest team size is not a valid reason to break a problem into microservices. The problem itself is the thing to analyze.

I personally know of a two person team that claims to have over 100 microservices. I think most are just lambda functions however.

Sure, but the question was - are they forced to split new microservices just because they have more people? Or is it just how they decided to split up the app in a logical way.

Reply on news.ycombinator.com