Introduction
The choice of an architectural style is one of the fundamental technical solutions in 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 is the most preferred architectural style. In the process, I will try to draw a logical chain that explains the development of architectural styles from monoliths to microservices.
The last time we dealt with the monolith and came to the conclusion that the monolith has a number of problems: the size, connectivity, deployment, scalability, reliability and conservatism.
This time I propose to talk about the possibilities of organizing the system in the form of a set of modules / libraries (component-oriented architecture) or services (service-oriented architecture).
Component-oriented architecture
Component-based architecture implies the implementation of the system as a set of components that can be used in both current and future projects. When dividing a system into components, the following factors are taken into account: their suitability for reuse, their substitutability, independence from context, extensibility, encapsulation and independence.
With proper use of components, the problem of a “big ball 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 a running process: for example, a web application and a database are deployed together.
Most often, monoliths are designed as a set of modules. This approach leads to ensuring the independence of development, but at the same time the problems of independent scaling and deployment, fault tolerance and independence from the general technological stack remain. This is why the module is a partially independent component.
The biggest 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 trash heap, 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 is engaged in code review at full time and beats the hands of developers who violate the logical structure.
An "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: interoperability of user-oriented applications, reusability of business services, independence from a set of technologies and autonomy (independent evolution, scalability and deployability).
Service-oriented architecture (SOA) solves all of the monolith's outlined problems: a change affects only one service, and a well-defined API supports good component encapsulation.
But not everything is so smooth: SOA introduces new problems. Remote calls are more expensive than local calls, and redistribution of responsibilities between components has become significantly more expensive.
By the way, the ability to deploy independently is a very important feature of the service. If services are to be deployed together, or even more so in a certain sequence, then the system cannot be considered service-oriented. In this case, they speak of a distributed monolith (it is considered an anti-pattern not only from the point of view of SOA, but also of a microservice architecture).
Service-oriented architecture is well supported by the architecture community and vendors. Hence, there are many courses and certifications, well-developed patterns. The latter includes, for example, the not unknown enterprise service bus (ESB = enterprise service bus). At the same time, ESB is the 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 emergence of microservices (~ 2015).
Conclusion
After we discussed the possibilities of organizing information systems in the form of services and modules, I propose to finally move on to the principles of a microservice architecture and pay special attention to the difference between a microservice architecture and a service-oriented architecture in the next part.
