On the way from monolith to microservices

Good day! To begin with, what will the article be about? This article is a succinct description of the experience of moving from a monolithic application to microservices. Let’s touch on the advantages of such a transition and touch on some of the problems that can be encountered in real development. Who might this article be useful for? For those who, for some reason, still doubt the effectiveness of microservice architectures. Also note that this article is not a tutorial. It aims to provide a brief introduction to the practice of moving from one architecture to another. For those who want to dive into the details of designing microservice architectures, I recommend reading the literature, you can start with the book by Chris Richardson “Microservices. Development and refactoring patterns. ” This will provide a good basis for further development. I will present the material using the example of building a hypothetical system for registering and onboarding sellers on a certain trading platform.

What is given?

The registration system, which stores information about the seller and his store, implements the process of filling in and storing legal data. Manages the processes of checking and approving the seller’s data, checking and signing an agreement between the trading platform and the seller, the processes of acquainting sellers with the main parts and tools used in the process of working on the site. It also implements a system of rewarding active sellers and punishing unscrupulous ones. Looking ahead, the functionality of child accounts will be added along the way. It might look like this.

Let’s dive into history.

At the very beginning of the emergence of projects, there is usually no precise and clear understanding of what will be in the system and what functions it will perform. It should be understood here that this is a normal situation in cases when you are not copying. Requirements at the very beginning are usually similar to “need to get some data.” Accordingly, the development fulfills the first needs. What we have in the given is the result of a certain period of time. One of the problems of microservices development can be noticed right there. In the beginning, the problem is uncertainty. What kind of services are needed, their number and purpose. Immediately I will cite one more feature that sometimes stimulates the growth of monoliths in an enterprise. It’s no secret that as companies grow, so do management processes. And a situation may arise when the development of microservices is quite acceptable, but obtaining resources is a procedure of various approvals and approvals, and it is not always quick and easy.

What can be done to try to avoid the growth of a monolith at the very beginning of a project’s life?

The first and probably the most important thing is the experience. If you have ever built similar systems, then this will at least predict possible further steps. And if you go down to more real things – this is close attention to the symptoms of the monolith. It is at the beginning of a project’s life that it is important to regularly analyze its functionality. Let’s try with our example. At the very beginning, we just collect data.

But at some point, it becomes noticeable that the data is quite clearly divided into domains. And if you see that, then it’s time to look at the possibility of separation. Perhaps it is worth organizing a separate service for collecting data about the seller and separately data about the store.

The next symptom is to highlight the volume and complexity of the application. Here you cannot give the exact measure in the form if you have 1K lines of code, this is still normal, and 1001 is already a monolith. No, rather, the measure is when you start to use different design patterns more and more actively. And not just some factories or strategies and chains of responsibilities, but the division into modules, the creation of some facades. When the list of what the application does is no longer possible to list conditionally on the fingers of one hand. This is also a sign that it might be worth dividing the application into several simpler ones.

Design

The first iteration is the breakdown of microservices by domains or core tasks. In our case, this was done at the stage given… In total, in the first approach we get 8 services.

Now that the system has begun to emerge, it’s time to take another look at the tasks of these services in more detail. The main reason is to try to eliminate code duplication, as well as try to ensure the principle of single responsibility for services. Let’s try to do this with our example. We have a seller approval process and a contract signing process. Both of them are likely to initiate the launch of a business process in a business process management system (BPMS) and then react to its result.

It can be assumed that working with a business process management system is not always trivial – from experience: API methods often have a fairly specific set of headers, often they contain computed signatures for signing a request, various time stamps. Considering that at least 2 services will work with the business process management system, we can conclude that we will have abundant code duplication. In addition, for requests, keys can be used to generate signatures or some kind of encryption – this means difficulties in maintaining the relevance of these keys, and we also need to receive processing results from the BPMS. Based on the reasoning, the conclusion suggests itself that this activity should be taken out into a separate service, which will become a facade facilitating interaction.

Rice. 6 Select the facade for working with BPMS

Announced Expansion of the Registration System

As we remember, each seller, in addition to his own account, can create more subsidiary accounts (in the case when the seller has several managers involved in trade management). Therefore, we look at our breakdown again and see that one more service can be distinguished – the registration process. What such a microservice will do: its main task will be to store registration steps for the seller and child accounts. The process of filling in the data can consist of a branched tree of steps, at each of which its own data set is filled in, its own specific validation is performed. Transitions between steps can have a complex set of rules.