Monoliths vs. microservices — benefits and drawbacks [a comparision]
What to choose as a system architecture? Monolith or microservices? What is better for our company? Focusing on microservices architecture is currently one of the most important technological trends, but also monoliths, especially the modular ones, have their advantages. In today's article, we present the benefits and drawbacks of each of the systems, and explain to whom and when the solution will work better in business.
Monolith or microservices? An important decision
It is said that systems architecture creates the future of a given business, and it is indeed so. Whether we choose a monolithic system or a system built on the microservices architecture will have consequences for many years to come — for the functioning of the company, for the speed of introducing changes and integration, as well as for security.
So, when a company builds a new central system on which all the company’s main processes are going to be based on, it simply needs to think carefully about its choice. Subsequent changes to the system architecture will not only be extremely expensive and long (often it takes many years until the system can be completely replaced), but also difficult — changing processes and switching to a new system often costs a lot of time and effort, and many employees are not able to adapt to changes without a huge amount of stress and difficulties.
Monoliths vs. microservices - a comparison of benefits and drawbacks
Monolithic systems
Let's start with monolithic systems, which are often associated - wrongly - with something outdated. Wrongly, because not every monolith is a legacy system at once, and if it is well-written and adapted to the company's business needs, and, importantly, it is regularly maintained, it can be used effectively for years.
Many successful companies, such as Netflix, Spotify, Twitter, Amazon, or Linkedin started their business based on a monolith. This approach is known as Monolith first. Later, as these companies grew, began to offer more services, and focused on rapid development, they switched to a microservice architecture that better served these tasks.
In the beginning, however, due to the ease of defining the requirements and the relatively low variety of services, the monolithic system was a better solution for them. It was efficient in a single process, and as it covered a fairly narrow domain that did not change over the years, the monolith worked great.
It is this simplicity at the start that seems to be the greatest advantage of monoliths. We do not have to think about the division of services and functions, as in the case of microservices, where we divide everything into independently operating small services communicating through the API network. Sometimes, at the beginning of a company's activity, we simply do not have anything to share yet - we only need one central system that will allow us to achieve business goals.
Now let's look at the most important advantages and disadvantages of monolithic architecture:
Trying to explain it in the easiest way, monolithic systems are systems that are implemented in the context of one application. They are defined as complex systems that are single units of implementation. They often have one database that is shared by all departments. This has the advantage that if we want to make a change in all services, it is enough to implement this change in one place, and not, as in the case of a microservice network, in each microservice.
However, this is also a drawback, because not all departments need exactly the same services and access. The downside is that such a central system does not allow many teams to operate independently of each other and force us to use only one technology, which often makes integration with other systems or API difficult.
What’s more, an error at some point in the system means that the whole system can crash in a second. Just like the flutter of a butterfly’s wing can cause a sandstorm on the other side of the hemisphere, so a small failure of the monolith can paralyze it completely (the so-called Butterfly effect). If the system is large, it takes weeks of time to find a critical location and search through hundreds of lines of code, so monolithic repairs are slow and expensive.
Due to the aforementioned lack of separation of services, the monolith is also more susceptible to external attacks — a data leak will immediately make the hacker have access to the entire system, not just a separate service.
However, what is most often accused of monoliths is low scalability and lack of flexibility to changes. For example, adjusting the system to the new format of accounting documents may take many weeks, and adding some new function, many months. In the case of microservice architecture, it is much easier and faster - we are not "once and for all" doomed to one technology and instead of "sticking" new functions to the central system (and often these stickers are, let's be honest, of poor quality), we simply change only one microservice or add a new one, removing another that no longer fulfills its function.
It is also important that by choosing a monolithic system, we condemn ourselves to one supplier — hardly anyone will take over such a system and take care of its maintenance or reconstruction. Technology companies then suggest switching to a new system or possibly refactoring. This is because when the monolithic system is to “hit” new hands, it is usually the legacy system [more about it HERE].
To sum up, a monolithic system — as long as we intend to take care of it — can be a good solution for newly-started companies that do not have great needs to implement changes quickly and who do not quite know what they want. It can also be a good choice when the system we need is to be relatively small and support one process.
Important!
It is worth choosing the so-called modular monolith — the younger brother of a typical monolithic system — which is characterized by the fact that it can be relatively easily divided into microservices later on. It is therefore a kind of golden mean between the monolithic and the distributed systems.
Microservices
Contrary to appearances, distributed systems are not micro-applications at all. This name refers not so much to the size of the system, but to the business functions it performs, i.e. the services. Microservice A is responsible for such a service, microservice B for such, and microservice C for another one. When deciding on the architecture of microservices, we choose the construction of many systems, each of which is fully autonomous, and then we connect them with each other via the input and output API, not necessarily tying them all together. It is not required at all — A can only contact B and not C.
Thanks to this, not all departments in the company have to have the same access, a failure in one place does not result in the location of the entire system, it is easy to integrate them with new services and develop.
In other words, the greatest disadvantages of monoliths are the greatest advantages of systems based on microservice architecture.
As can be seen in the above graphic, a significant advantage of distributed architecture is that we can freely choose the technology, and many teams can work independently of each other in different places of the network — replace smaller parts, introduce changes, adapt the system to the requirements “here and now”. This high scalability and flexibility to changes are advantages that cannot be denied to this solution.
But distributed systems also have their drawbacks. Providing the required security is much more difficult than in a monolithic system because communication here takes place over the network, not in memory. Network calls can fail, and there may be a delay. It is more difficult to analyze and debug in microservices and it is more difficult to guarantee transactionality in terms of ACID. Moreover, the complexity of the infrastructure that allows the architecture of distributed systems to function properly is growing rapidly.
So, just like in the case of monoliths, we have something for something.
In summary, the microservices architecture is a solution for companies that need to quickly implement new changes and scale their business, and that need a large system that can be broken down into smaller modules, in order to develop them autonomously later.
You might also like:
