To me, it's simply: It's easier, simpler 100x to manage 10 small services, than a service with 10 functionalities. Main reason is, i can easily swap out, replace any small service with better one. With big service, it's impossible !
So it leads to next lesson: Learn how to compose things, or, thinking in higher level: Thinking in composition.
Dividing your work up in to modules is sound advice.
What blows my mind as a non web developer, is that when people talk about micro services they connect these modules not using a function call, but as a HTTPS request over a network to a different machine!! The orders of magnitude of latency / performance / hardware / energy / bandwidth wasted establishing a connection to a remote machine using a text based protocol, vs a native C API call is mind boggling to me.
I don't understand how you can say this with a straight face, especially "100x". Operationally, multiple services is always more complex.
Unless there is something unique about the setup (E.g. one piece of functionality requires much higher scale, make sense for the domain, etc) it doesn't make sense to split things into independent services.
This sounds like a microservice vs monolith statement in disguise.
Respectfully I disagree, maybe with more context I’d be on a similar boat.
The communication overhead is a real challenge to be reckoned with. I don’t think the mere fact something has 10 functions in one service makes it better or worse than breaking those out into their own services (not even getting into at what level do you break them down? Since most all code is a composition of functions)
Personally I go monolith first, then if and only if there’s a function of the monolith that needs to scale separately from the rest of its parts, then I’ll consider making it its own service (and this has to be a pretty large extreme to take on this burden)
Too many times I’ve been burnt by attempts at micro services, which seem to stagnate faster than monoliths at some companies. I also think there’s a higher degree of documentation each new service made, vs keeping it an endpoint in a monolith. But I digress
There's an in-between point that I think is more common than good microservices, that I think you're describing, that I've seen called a "distributed monolith". Basically what happens when the microservices are too intertwined to be independently replaceable as GP suggests.
So it leads to next lesson: Learn how to compose things, or, thinking in higher level: Thinking in composition.