Hello habr. Enrollment for a new course stream is open at OTUS right now . In anticipation of the start of the course, I want to share with you my author's article.
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.
A bit of history
If you try to ask developers a question: “Why do we need microservices?”, You will get a variety of answers. You will hear that microservices improve scalability, make code easier to understand, improve fault tolerance, sometimes you can hear that they allow you to “clean up the code”. Let's take a look at history to understand the purpose of microservices.
In short, microservices in our current understanding arose as follows: in 2011, James Lewis, analyzing the work of various companies, drew attention to the emergence of a new “micro-app” pattern that optimized SOA in terms of speeding up the deployment of services. Somewhat later, in 2012, at the architectural summit, the pattern was renamed to microservice. Thus, the original goal of introducing microservices was to improve the notorious time to market.
Microservices were on the “hype wave” in 2015. According to some studies, not a single conference was complete without a report on the topic of microservices. Moreover, some conferences were devoted exclusively to microservices. Now, many projects start using this architectural style, and if the project contains tons of legacy code, then migration to microservices is probably being actively carried out.
Despite all of the above, there is still a fairly small number of developers who can define the concept of "microservice". But we'll talk about that a bit later...
Monolith
The architectural style opposed to microservices is the monolith (or all-in-one). It probably doesn’t make sense to tell what a monolith is, so I will immediately list the shortcomings of this architectural style that initiated the further development of architectural styles: size, connectivity, deployment, scalability, reliability and inertia. Below I propose to examine each of the shortcomings separately.
Size
The monolith is very large. And he usually communicates with a very large database. The application becomes too large to be understood by a single developer in principle. Only those who have spent a lot of time behind this code can work well with a monolith, while beginners will spend a lot of time trying to figure it out with a monolith and not the fact that they will figure it out. Usually, when working with a monolith, there is always some “conditional” senior who knows the monolith more or less well and beats other new developers for a year and a half. Naturally, such a conditional senior is a single point of failure, and his departure can lead to the death of the monolith.
connectedness
The monolith is a "big ball of mud", changes in which can lead to unpredictable consequences. Making changes in one place, you can damage the monolith in another (the same “ear scratched, * @ fell off”). This is due to the fact that the components in the monolith have very complex and, most importantly, non-obvious relationships.
Deployment
The deployment of a monolith, due to the complex relationships between its components, is a long process with its own ritual. Such a ritual is usually not definitively standardized and is transmitted by word of mouth.
Scalability
Monolith modules can have conflicting resource requirements, requiring compromise from a hardware point of view. Imagine that your monolith consists of services A and B. Service A is demanding on the size of the hard disk, and service B is demanding on RAM. In this case, either the machine on which the monolith is installed must support the requirements of both services, or you will have to manually, artificially disable one of the services.
Another example (more classic): service A is much more popular than service B, so you want services A to be 100 and services B to be 10. Again, two options: either we deploy 100 full-fledged monoliths, or on some then of them, services B will have to be disabled by hand.
Reliability
Since all services are together, if the monolith falls, then all services fall at once. In fact, this may not be so bad, at least there will be no partial failures in a distributed system, but on the other hand, due to an error in the functionality that 0.001% of users use, you can lose all users of your system.
inertia
Due to the size of the monolith, it is difficult to switch to new technologies. As a result, retention of that very conditional senior is a separate task. The technological stack chosen at the start of the project can become a block that hinders the development of the product.
Conclusion
Next time we'll talk about how people have tried to solve these problems by moving on to components and SOA.
Read more:
Source: habr.com