Size of microservices

Before we start building our microservices, we should be clear about a few of its basic aspects, such as what factors to consider while sizing our microservices and how to ensure their isolation from the rest of the system.

As the name suggests, microservices should be micro. A question arises: what is micro? Microservices is all about size and granularity. To understand this better, let's consider the application discussed in Chapter 1, What are Microservices?

We wanted the teams working on this project to stay synchronized at all times with respect to their code. Staying synchronized is even more important when we make a release of the complete project. For this, we needed to first decompose our application/specific parts into smaller functionalities/segments of the main service. Let's discuss the factors that need to be considered for high-level isolation of microservices:

• Risk due to requirement changes: Changes in the requirements of one microservice should be independent of other microservices. In such a case, we will isolate/split our software into smaller services in such a way that if there are any requirement changes in one service, they will be independent of another microservice.
• Functionality changes: We will isolate the functionalities that are rarely changed from the dependent functionalities that can be frequently modified. For example, in our application, the customer module notification functionality will rarely change. But its related modules, such as Order, are more likely to have frequent business changes as part of their life cycle.
• Team changes: We should also consider isolating modules in such a way that one team can work independently of all the other teams. If the process of making a new developer productive--regarding the tasks in such modules--is not dependent on people outside the team, it means we are placed well.
• Technology changes: Technology use needs to be isolated vertically within each module. A module should not be dependent upon a technology or component from another module. We should strictly isolate the modules developed in different technologies or stacks or look at moving them to a common platform as our last resort.

We can say that our primary goal should not be to make services just as small as possible; instead, our goal should be to isolate the identified bounded context and keep it small.