Size of microservices

Before we start building our microservices, we should be clear about a few of their 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 are all about size and granularity. To understand this better, let's consider the application discussed in Chapter 1, An Introduction to 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 release the complete project. 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 the high-level isolation of microservices:

• Risks 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 well placed.
• Technology changes: Technology use needs to be isolated vertically within each module. A module should not be dependent on 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 a last resort.

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