How big should microservices be? Should their size be based on lines of code? Developer hours? REST endpoints? Data entities?
About the only real solid guiding principle you can find is “it should do one thing, and do it well.” But what is that “one thing” for a microservice? Is it that it can handle the User object? Or is it that it can handle changing the User’s password?
Another common piece of advice is that a microservice should be small enough so that a developer basically has no reservations about rewriting the service. To me, this seems like a rather odd metric to use to gauge the size of a service. I understand that the idea behind it is that a developer could come in without any foreknowledge of the service, look at its API, and rewrite the service in order to fix a bug in the service, or to fix a performance issue, or whatever. In some cases that would be faster than actually digging in and debugging and finding the underlying issue. But that ignores the fact that in fixing that one bug, the developer could introduce many new bugs. Having a good automated test suite can help as a safety net here, but if your safety net were comprehensive enough to catch all the bugs, it would take too long to run (and wouldn’t you have caught that first bug too?).
In our microservices, we basically go by how many hands are in the pot at the same time, and the size of the database schema. If a service is too big, you will have many developers, possibly from different teams, all working on the same service. This obviously causes issues, and the service typically can be split into multiple services based on what each developer/team is really in there working on. Sometimes the data schema helps us to consolidate multiple services into one service. If a lot of data has to be duplicated, or is very similar between two different microservices, that could be an indication that the services could live very happily as one service.
Nobody has found that utopic metric of what a microservice should look like, and nobody ever will. It is different for each individual use case, and the different forces at work for them. Like so much in software, the question becomes a balancing act between competing factors.
Originally Posted on my Blogger site May of 2017