The term micro in microservice suggest that services should be decomposed in very small units. Martin Fowler recommend a size range that varies between a service-per-person and a service-per-dozen-people meaning that a microservice should not be maintained by a team of more than a dozen people. This follows the notion of the Two Pizza Team organizations used at Amazon. Following my own experience, micro services are maintained by small multidisciplinary teams varying between two to six people. More important is the domain surface the micro service covers. DDD advise to divide a unified model in smaller units named bounded context. Defining a service as covering no more than one bounded context is a comfortable way to constraint the size of your services.
So, cohesion is certainly a good way to define the service boundaries but in my opinion, this does not matter that much. A factor that is far more concrete is the speed and comfort with which developers can work on the service. Developers that can get rapid feedback on their work by building rapidly, debug easily and test their code continuously on their own pc are in a far better position that those that have to deploy the system to an integration environment and wait for other devs to deploy their code before they can test their own work.
Therefore, I think that size of the service does not matter that much. What’s really important is that the architecture of the system should account for autonomy.
Rather than emphasizing one rigid size for microservices, I prefer to make sure my services adheres to different forms of autonomy:
- Runtime autonomy: The system should survive during a certain amount of time to a failure of one of its parts.
- Testing autonomy: One should be able to test the parts of a system in isolation.
- Change autonomy: One should be able to do modification without impacting other parts of the system.
- Platform autonomy: The system should be able to run on platforms with different kind of hosting infrastructure.