Hey Habr. Today I continue a series of publications that I wrote specifically for the start of a new course stream. .
Introduction
The choice of architectural style is one of the fundamental technical decisions when building an information system. In this series of articles, I propose to analyze the most popular architectural styles for building applications and answer the question of when which architectural style is most preferred. In the process of presentation, I will try to draw a logical chain that explains the development of architectural styles from monoliths to microservices.
В we figured out the monolith and came to the conclusion that the monolith has a number of problems: size, connectivity, deployment, scalability, reliability and rigidity.
This time I propose to talk about the possibilities of organizing a system as a set of modules / libraries (component-oriented architecture) or services (service-oriented architecture).
Component-Oriented Architecture
Component-oriented architecture involves the implementation of the system as a set of components that can be used both in current and future projects. When splitting the system into components, the following are taken into account: their suitability for reuse, their substitutability, context independence, extensibility, encapsulation and independence.
With proper use of components, the problem of a “big clod of dirt” (large size + high connectivity) is solved, and the components themselves can be both assembly units (modules, libraries) and deployment units (services). Deployment units are not always mapped to the running process: for example, a web application and a database are deployed together.
Most often, monoliths are developed as a set of modules. This approach leads to development independence, but the problems of independent scaling and deployment, fault tolerance and independence from the common technology stack remain. That is why the module is a partially independent component.
The main problem with such a monolith is that the division into modules is purely logical and can be easily broken by developers. A core module may appear, which gradually turns into a garbage can, a graph of dependencies between modules may grow, and so on. To avoid such problems, development should be carried out either by a very mature team, or under the guidance of an “architect” who does full-time code review and beats the hands of developers that violate the logical structure.
The "ideal" monolith is a set of logically separated modules, each of which looks into its own database.
Service Oriented Architecture
If, nevertheless, it is supposed to organize the system in the form of a set of services, then we are talking about a service-oriented architecture. Its principles are user-facing application compatibility, business service reuse, technology set independence, and autonomy (independent evolution, scalability, and deployment).
Service oriented architecture (SOA = service oriented architecture) solves all the problems of the monolith: only one service is affected when changing, and a well-defined API maintains good encapsulation of components.
But not everything is so smooth: SOA leads to new problems. Remote calls are more expensive than local ones, and the redistribution of responsibilities between components has become significantly more expensive.
By the way, the possibility of independent deployment is a very important feature of the service. If services must be deployed together, or, moreover, in a certain sequence, then the system cannot be considered service-oriented. In this case, one speaks of a distributed monolith (it is considered an anti-pattern not only in terms of SOA, but also in terms of microservice architecture).
Service-oriented architecture is well supported by the architecture community and vendors. This implies the presence of many courses and certifications, well-developed patterns. The latter include, for example, the well-known enterprise service bus (ESB = enterprise service bus). At the same time, ESB is baggage from vendors, it does not have to be used in SOA.
Service-oriented architecture peaked in popularity around 2008, after which it began to decline, which became much sharper after the advent of microservices (~2015).
Conclusion
After we have discussed the possibilities of organizing information systems in the form of services and modules, I propose to finally move on to the principles of microservice architecture and pay special attention to the difference between microservice architecture and service-oriented architecture in the next part.
Source: habr.com