Pluses of microservice architecture
Acquaintance with microservice architecture seriously changed my approach to development. In this publication I will talk about various aspects of using microservices. To illustrate some of them, I will use the architecture of a real estate rental project.
Experimental application
The client views the list of available apartments and reserves them, he can also place his apartments on the service.
In the classical approach, a framework is most often chosen for building and components are implemented inside it. In the case of microservices for each component, a separate application is built and a set of tools is selected. Components most often interact through the REST API.
Components: C - data for apartments (core), 1 - booking, 2 - payment, 3 - booking logging, 4 - placement of apartments, 5 - content administration.
')
Please note that before creating a microservice application, you will have to think over the business logic and break the application into self-sufficient components. Now let's talk about why microservices are cool.
Just use a hammer to hammer in nails. This applies to the development of IT products.
For example, consider the third component of our application - logging. In the most basic sense, we just need to write the text in different files.
It turns out that we do not need a complex framework and database. For implementation it will be enough to have a simple module for writing to files, rest-api, and quite a few people / hours for development and support.
Dozens of SaaS solutions appear on the market every day that solve a wide variety of tasks. And if we understand that it is easier to use such a solution than to maintain our own, then we can simply remove one of our microservice and replace it with a SaaS service. In this case, you will need to change only the interaction with the API.
Here the most suitable example would be the payment service (the second component). However, it is more appropriate to talk about the transition from SaaS-solutions to his. For example, to reduce the percentage of commission.
Within the framework of one project, you will have to deal with interaction logic for different types of users. The attendants of your project (for example: administrators and moderators) are no exception (modules 4 and 5).
However, it should be borne in mind that the needs of these groups are different and each of them has its own interface. It would be great if the logic of a separate interface matches the logic of the application. This will allow working on the task at a new qualitative level.
When 20+ people work on the code of a single project, even with a very good architecture, this causes problems. Bugs become much more, testing turns into torture, etc. As a result, the product is very difficult to develop and it is almost impossible to make a quality race through updates.
Allocation of each significant component to a separate microservice allows not only to improve the quality of development, but also to reduce the number of developers within the framework of existing tasks, and to release the released person / hours for new developments.
As a result, each of the 6 components will be serviced by 1-3 developers. And in their work, they will not overlap with colleagues from parallel microservices. It is also worth noting that it will be convenient to work with microservices within versioning, which is easily implemented in the classical API.
Perhaps it seems to you now redundant and complex, as it would seem in the case of any intervention in your usual ecosystem of development. However, microservice architecture is definitely worth a try, at least once, for free.
And the basic functions of each new product can be collected from ready-made microservices. And this is just great!
For an in-depth study of the concept, I recommend reading this publication here: habrahabr.ru/post/249183 .
Microservice design
Experimental application
The client views the list of available apartments and reserves them, he can also place his apartments on the service.
In the classical approach, a framework is most often chosen for building and components are implemented inside it. In the case of microservices for each component, a separate application is built and a set of tools is selected. Components most often interact through the REST API.
Components: C - data for apartments (core), 1 - booking, 2 - payment, 3 - booking logging, 4 - placement of apartments, 5 - content administration.
')
Please note that before creating a microservice application, you will have to think over the business logic and break the application into self-sufficient components. Now let's talk about why microservices are cool.
Each task has its own tool.
Just use a hammer to hammer in nails. This applies to the development of IT products.
For example, consider the third component of our application - logging. In the most basic sense, we just need to write the text in different files.
It turns out that we do not need a complex framework and database. For implementation it will be enough to have a simple module for writing to files, rest-api, and quite a few people / hours for development and support.
No irreplaceable
Dozens of SaaS solutions appear on the market every day that solve a wide variety of tasks. And if we understand that it is easier to use such a solution than to maintain our own, then we can simply remove one of our microservice and replace it with a SaaS service. In this case, you will need to change only the interaction with the API.
Here the most suitable example would be the payment service (the second component). However, it is more appropriate to talk about the transition from SaaS-solutions to his. For example, to reduce the percentage of commission.
To each his own
Within the framework of one project, you will have to deal with interaction logic for different types of users. The attendants of your project (for example: administrators and moderators) are no exception (modules 4 and 5).
However, it should be borne in mind that the needs of these groups are different and each of them has its own interface. It would be great if the logic of a separate interface matches the logic of the application. This will allow working on the task at a new qualitative level.
You are small even when you are big
When 20+ people work on the code of a single project, even with a very good architecture, this causes problems. Bugs become much more, testing turns into torture, etc. As a result, the product is very difficult to develop and it is almost impossible to make a quality race through updates.
Allocation of each significant component to a separate microservice allows not only to improve the quality of development, but also to reduce the number of developers within the framework of existing tasks, and to release the released person / hours for new developments.
As a result, each of the 6 components will be serviced by 1-3 developers. And in their work, they will not overlap with colleagues from parallel microservices. It is also worth noting that it will be convenient to work with microservices within versioning, which is easily implemented in the classical API.
Results
Perhaps it seems to you now redundant and complex, as it would seem in the case of any intervention in your usual ecosystem of development. However, microservice architecture is definitely worth a try, at least once, for free.
And the basic functions of each new product can be collected from ready-made microservices. And this is just great!
For an in-depth study of the concept, I recommend reading this publication here: habrahabr.ru/post/249183 .
Subsistence
Microservice design
Source: https://habr.com/ru/post/261237/
All Articles