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.
A bit of history
If you try to ask a question to developers: "Why do we need microservices?", Then you will get a variety of answers. You will hear that microservices improve scaling, make your code easier to understand, improve fault tolerance, sometimes you will hear that they allow you to "clean up the code." Let's go back to history to understand what the purpose of the emergence of microservices was.
In short, microservices in our current understanding emerged as follows: in 2011, James Lewis, analyzing the work of various companies, drew attention to the emergence of a new pattern "micro-app" that optimized SOA in terms of accelerating service deployment. A little later, in 2012, at the architecture summit, the pattern was renamed to microservice. Thus, the initial 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 talk on the topic of microservices. Moreover, some conferences were dedicated exclusively to microservices. Nowadays, many projects start using this architectural style, and if the project contains tons of legacy code, then most likely the migration to microservices is actively carried out.
Despite all of the above, there are still quite a few developers who can define the term "microservice". But we will talk about this a little later ...
Monolith
The architectural style versus microservice is 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, coherence, deployment, scalability, reliability, and inertia. Below I propose to get to know each of the disadvantages separately.
The size
The monolith is very large. And he usually communicates with a very large database. The application is getting too big for one developer to understand at all. 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 out the 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 slaps other new developers for a year or 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
A monolith is a "big ball of mud", changes in which can lead to unpredictable consequences. By making changes in one place, you can damage the monolith in another (the same "scratched my ear, * @ fell off"). This is due to the fact that the components in the monolith have very complex and, most importantly, non-obvious relationships.
Deployment
Deploying a monolith, due to the complex relationships between its components, is a long process with its own ritual. Such a ritual is usually not completely standardized and is passed by word of mouth.
Scalability
Monolith modules can have conflicting resource requirements, which necessitates a compromise in terms of hardware. Imagine that your monolith consists of services A and B. Service A is demanding on the size of the hard disk, while 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 disable one of the services by hand.
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 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, perhaps this is not 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, the retention of that 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 tried to solve these problems by moving on to components and SOA.
Read more: