Hello, Habr. Today, I continue the series of publications written specifically for the launch of the new stream of the course. .
Introduction
Choosing an architectural style is one of the fundamental technical decisions when building an information system. In this series of articles, I propose to explore the most popular architectural styles for building applications and answer the question of when each architectural style is the most preferable. Throughout the discussion, I will try to establish a logical chain that explains the evolution of architectural styles from monoliths to microservices.
In We have dealt with the monolith and found that it has several issues: size, coupling, deployment, scalability, reliability, and rigidity.
This time, I propose to discuss 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 system being executed as a set of components that can be used in both current and future projects. When breaking the system into components, factors considered include: reusability, substitutability, context independence, extensibility, encapsulation, and autonomy.
With proper use of components, the problem of the 'big ball of mud' (large size + high coupling) is resolved, and the components themselves can represent both units of assembly (modules, libraries) and units of deployment (services). Deployment units do not always correspond to the executing process: for example, a web application and a database are deployed together.
Most often, monoliths are developed as a set of modules. This approach ensures development independence, but issues with independent scaling and deployment, fault tolerance, and dependence on the overall tech stack remain. This is why a module is considered a partially independent component.
The main problem of such a monolith is that the division into modules is purely logical and can easily be violated by developers. A core module may slowly turn into a dumping ground, and the dependency graph between modules may grow, among other issues. To avoid such problems, development should be carried out either by a very mature team or under the guidance of an 'architect' who dedicates full time to code review and disciplines developers who violate the logical structure.
An 'ideal' monolith consists of a set of logically separated modules, each looking into its own database.
Service-Oriented Architecture
If the organization of the system is still planned in the form of a set of services, we are talking about service-oriented architecture. Its principles include: compatibility of user-oriented applications, reuse of business services, independence from the technology stack, and autonomy (independent evolution, scalability, and deployment).
Service-oriented architecture (SOA) addresses all the identified issues of monoliths: when changes occur, only one service is affected, and a clearly defined API ensures good encapsulation of components.
However, it's not all smooth sailing: SOA leads to the emergence of new problems. Remote calls are more expensive than local ones, and the redistribution of responsibilities among components has become significantly costlier.
Moreover, the ability to deploy independently is a very important feature of a service. If services must be deployed together or, even more so, in a specific sequence, then the system cannot be considered service-oriented. In such cases, we talk about a distributed monolith (considered an anti-pattern not only from the perspective of SOA but also of microservices architecture).
Service-oriented architecture is well-supported by the architectural community and vendors. This is evident from the availability of numerous courses and certifications as well as well-developed patterns. One such example is the well-known enterprise service bus (ESB). However, the ESB is vendor baggage and does not have to be used in SOA.
The peak popularity of service-oriented architecture occurred around 2008, after which it began to decline, with the downtrend becoming significantly more pronounced following the emergence of microservices (~2015).
Conclusion
After discussing the possibilities of organizing information systems in the form of services and modules, I suggest we finally move on to the principles of microservices architecture and pay special attention to the differences between microservices architecture and service-oriented architecture in the next part.
Source: habr.com
