Characteristics of microservices, applications and systems
Hello!
I want to present an interesting presentation of Stefan Tilkov from the founder and chief consultant in inQ to the attention of the community . Stefan talks about the idea of ​​separating large systems into small applications that are responsible for different aspects of the system. The idea itself is not new, but the author rests on the fact that the main reason for this separation must be isolation . Due to the boundaries of the applications thus obtained, it is more difficult to obtain related modules, which in fact should be independent. Here, we can also recall the “domains boundary” approach, to separate domain entities by application, instead of creating a single data model for the entire large organization / process.
')
An additional advantage of isolation is the ability to point-scale parts of the system depending on the loads. This process can be localized in one team, so that they, in proportion to their knowledge and tools, perform the task within the boundaries of the isolated subsystem.
In the presentation, Stefan also talks about the fact that traditional assumptions about how to build software systems are subject to total revision today. One of these assumptions is that a large system should have a single environment, often with a one-to-one correspondence between the functional requirements of the project and the implementation, which results in the formula “1 project = 1 system”. Although this solution is not always the best, it turns out to be very tough.
Considering the way of constructing logical systems from small parts, Tilkov describes three styles:
Comparing the different approaches to the implementation and characteristics of such systems, the author emphasizes that there is still no consensus on how to do it correctly and effectively. However, Stefan wants to show the breadth of available options.
The most interesting parameter for Tilkov is the number of modules in the system, because it shows the degree of decomposition of a large system. Large systems in this regard lose, but microservices are more difficult to support and orchestrate, thereby increasing the level of complexity of the system. In general, there is no one right decision, a “silver bullet” and we at the API & Backend conference would like to raise a discussion on this topic. If you have interesting cases from the practice regarding typical problems for a particular model, ways to solve these problems, we are waiting for your stories .
I want to present an interesting presentation of Stefan Tilkov from the founder and chief consultant in inQ to the attention of the community . Stefan talks about the idea of ​​separating large systems into small applications that are responsible for different aspects of the system. The idea itself is not new, but the author rests on the fact that the main reason for this separation must be isolation . Due to the boundaries of the applications thus obtained, it is more difficult to obtain related modules, which in fact should be independent. Here, we can also recall the “domains boundary” approach, to separate domain entities by application, instead of creating a single data model for the entire large organization / process.
')
An additional advantage of isolation is the ability to point-scale parts of the system depending on the loads. This process can be localized in one team, so that they, in proportion to their knowledge and tools, perform the task within the boundaries of the isolated subsystem.
In the presentation, Stefan also talks about the fact that traditional assumptions about how to build software systems are subject to total revision today. One of these assumptions is that a large system should have a single environment, often with a one-to-one correspondence between the functional requirements of the project and the implementation, which results in the formula “1 project = 1 system”. Although this solution is not always the best, it turns out to be very tough.
Considering the way of constructing logical systems from small parts, Tilkov describes three styles:
- Microservices are small programs, each of which works on its own. Use simple mechanisms for communication and are built around the needs of the business.
- Applications are small, separate, executable programs using the “ share nothing ” model. They have a lot in common with microservices.
- Self-contained systems are large standalone programs that contain both data and logic. Controlled by one team. Do not use synchronous remote calls, can provide API.
Comparing the different approaches to the implementation and characteristics of such systems, the author emphasizes that there is still no consensus on how to do it correctly and effectively. However, Stefan wants to show the breadth of available options.
The most interesting parameter for Tilkov is the number of modules in the system, because it shows the degree of decomposition of a large system. Large systems in this regard lose, but microservices are more difficult to support and orchestrate, thereby increasing the level of complexity of the system. In general, there is no one right decision, a “silver bullet” and we at the API & Backend conference would like to raise a discussion on this topic. If you have interesting cases from the practice regarding typical problems for a particular model, ways to solve these problems, we are waiting for your stories .
Source: https://habr.com/ru/post/256189/
All Articles