3 ms·
This irritates me. People keep forgetting about costs of maintaining services. What is a cost of maintaining a service? What is a cost of maintaining equivale
by lmilcin 5y ago
This irritates me. People keep forgetting about costs of maintaining services.
What is a cost of maintaining a service?
What is a cost of maintaining equivalent amount of code as a separate module in a larger service?
The reality is that plopping a piece of code to its own separate module and then maintain communication within the service (ie. call another class) is usually much easier and cheaper than creating new services.
I get that creating a new service might be fun, but if you compare costs of maintaining a thousand services vs cost of maintaining of single application with a thousand modules it is not given that the services are going to be cheaper.
I think there is no rule to decide how big a service should be. How big a module should be?
Rather, services should be split when there is some essential reason to do so. For example, the functionalities might have some intrinsic differences that make it costly to reconcile within a single service. Or you might have a functionality that does not scale linearly and so it might make sense, from performance point of view, to maintain less nodes of that service but fully devoted to executing particular functionality.
Another good reason might be if you have separate teams maintaining the functionality -- separate services might allow the teams to work more independently, make independent technology decisions, etc.
Splitting services just because code size of single service will be smaller is stupid. The total code size is the same -- each part of functionality is still somewhere. Actually, you need more code just for the overhead of having separate services.
If hiding code is your aim, just put it in another folder and squint your eyes so you don't see it. See? How easy?
If defining good APIs is your aim, just do good job defining modules within single service. Do you really need overhead of separate service for that?
So, the good general rule, as with practically anything in life, would be: Split services if you see gains that are bigger than costs and risks.
Actually, much bigger, because your attention is also finite resource. If you spend 50% of your time talking about creating services you are not spending that time focusing on other important stuff.
But don't just split services because they are bigger than your head.
This just irritates me.