Microservice

There are different processes for implementing microservices around the world. However, in general, each service must have a separate and unique logic and data model with the least amount of dependency on other services. Therefore, the team working on each service can think independently about developing their software.

Ultimately all services want to send and/or receive information from other services. If the data models are very different from each other, another separate logic must be written for each data to be coordinated. In some microservice development models, it is preferred that the data model designed for services be as consistent as possible because different services can have many common features.

Consider an ERP as an example. We have a service for accounting, a service for warehousing, and a service for running a store. All three of these services work with an entity called a product. Changing the product entity in any of these services affects the other services as well. For example, if a product is sold, the warehouse must be notified so that it can replace it in the store in time, and accounting must also have sales information to do its job. Therefore, if the product entity is consistent across all three services, writing server-side logic will be easier. In this type of microservice development, there is usually a senior programmer who knows about all three services and designs their models. This procedure will somewhat reduce the independence of services but ultimately create less trouble for development.

Another problem that arises in microservices is the lack of data consistency. Take the same ERP example. If a product is sold but not registered in the accounting service or removed from the warehouse but not registered in the store, it will cause data inconsistency. To reduce these inconsistencies, a tool called a message broker is recommended. With this tool, all messages that are supposed to be exchanged between two services are sent to an independent service and stored there. If a service does not work properly, messages are not lost and as a result, data always remains consistent and coordinated.

The next issue in microservices is the distribution of server-side hardware resources. If we have a large number of services, managing the processors of these services will be complicated and we will need many tools to analyze requests so that we can know the amount of hardware resources involved in running each piece of code. In addition, the exchange of messages between services is also an additional processing load that must be performed. Also, the repetitions created from the data require not only additional space for storage but also the need to write parallel logic because each logic processes a separate data. However, the main problem in distribution of processing load arises at the time of horizontal-distribution. If the data is integrated in one place, managing the distribution of processing load will be simple but when each service has its own database and processing load and at the same time needs other service data, distribution of processing load for it requires considering these dependencies. Given the limitations of vertical-distribution, removing obstacles to horizontal-distribution is essential. Lesan offers small solutions for implementation of microservices that can reduce their implementation complexity. It also proposes a new process that has an architecture between microservices and monoliths that will be explained next.