官术网_书友最值得收藏!

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 1What 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.

主站蜘蛛池模板: 信阳市| 交口县| 哈尔滨市| 柳林县| 杭锦旗| 平阳县| 临武县| 济宁市| 东安县| 农安县| 论坛| 仁怀市| 思茅市| 临沂市| 鄂伦春自治旗| 安顺市| 祁东县| 巧家县| 铜鼓县| 额济纳旗| 保山市| 九江县| 新平| 广汉市| 临江市| 大竹县| 浑源县| 漳州市| 南溪县| 凤庆县| 石泉县| 政和县| 宝清县| 广南县| 张掖市| 吉安县| 峨边| 淄博市| 资源县| 南皮县| 富裕县|