> if you need to scale the number of teams working on the same product
You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice.
> if you need to scale the (monolith) service and it is too expensive to just scale it n times.
Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice.
I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.
I’ve seen the library approach in practice. It is works to a certain point, but it isn’t too long until having a single deployable[1] artifact becomes as much of a bottleneck as having a single codebase, if not more. Taking this approach makes it harder to do other things that are just as important, such as continuous delivery, empowering development teams to take ownership of operational excellence, or even ship updates in a reliable and timely fashion.
Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it.
[1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.
To my siblings: you don't know how libraries work.
If you understand binary compatibility you can deploy a library without deploying its client applications/libraries (they would need to be restarted, however).
In fact, this is one of the very reasons people invented shared libraries! It's why, for example, Linux distros are based on shared libraries: one can update large swaths of the system by updating a single package.
If your languages don't support this then it would be very unfortunate indeed.
You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice.
> if you need to scale the (monolith) service and it is too expensive to just scale it n times.
Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice.
I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.