By Michał Jaracz | Software Developer
It is said that systems architecture creates the future of a given business. So, when a company builds itself a new central system, it simply has to think it’s chosen well. Principally because the subsequent change of the system architecture will not only be extremely expensive and long (often years pass until the system can be completely replaced), but also difficult – changing processes and switching to a new system often costs the organization a lot of time and effort, and many employees find adapting to the changes stressful and difficult. Below, we list the pros and cons of monolithic and microservices-based applications to help you choose between the two approaches.
What is Monolithic Architecture?
By definition, a monolithic architecture is a type of software program where the entire application is designed as a single, self-contained unit. The concept of a monolithic approach can be explained as a large piece of software made up of multiple modules. Referred modules are tightly coupled with each other. The business logic and application are combined into a single deployable binary called a monolith. A monolith usually consists of three tiers: a database, user interface, and server-side application.
To many people, unjustly, monolithic architecture is associated with outdated architecture. Not every monolith is immediately a legacy system, and if it is well written and adapted to an enterprise’s business needs, and maintained regularly, it can serve effectively for years. Many of today’s successful giants such as Netflix, LinkedIn, Amazon, Spotify, and Twitter started their businesses precisely based on monoliths. This approach is known as the Monolith First. Only later, as these companies grew, began to offer more services, and set their minds on rapid growth, did they switch to a microservices architecture that better fulfilled these tasks.
What is Microservices Architecture?
Distributed systems are, contrary to appearances, not micro-applications at all. The name refers not so much to the size of the system, but to the business functions they perform, i.e. the services in question.
Microservice A is responsible for one type of service, microservice B for another, and microservice C for yet another, and so on. So when we decide on a microservices architecture, we choose to build multiple systems, each of which is fully autonomous, and then connect them via input and output APIs, without necessarily tying them all together. This is not required at all – A can only contact B, and doesn’t have to contact C either. This way, not all departments in the company need to have the same access, a failure in one place doesn’t put the whole system down, and it’s easy to integrate with new services and expand.
Pros and Cons of Monolith System
Monolithic systems are, in the simplest terms, those systems that are implemented in the context of a single application. They are defined as complex systems that are single implementation units. They often have a single database that is shared by all departments. This has the advantage that if you want to make a change to all services, you only need to implement the change in one place, rather than, as in the case of microservices networks, in each microservice. However, this is also a disadvantage, because not all departments always need the same services and access.
The downside is also that such a centralized system does not allow multiple teams to operate independently of each other and uses only one technology, making integration with other systems or APIs often difficult.
What’s more, a mistake somewhere in the system makes it so that the whole system can fall in an instant. Just as the flutter of a butterfly’s wings can cause a sandstorm on the other side of the hemisphere, a small failure of a monolith can cripple it entirely (the so-called Butterfly Effect). If the system is large, it takes weeks to find a hot spot and sift through hundreds of lines of code, so monolith repairs are slow and expensive.
Due to the aforementioned lack of separation of services, a monolith is also more vulnerable to external attacks – a data leak will immediately give a hacker access to the entire system, not just a separate service.
What monoliths are most often accused of, however, is low scalability and lack of flexibility for change. For example, adapting a system for a new format of accounting documents can take many weeks, and adding some new functions, many months. In the case of microservices architecture, it is much easier and faster – we are not “once and for all” doomed to one technology, and instead of “docking” new functions to the central system (and often these docks 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’s also not insignificant that by opting for a monolithic system, we are, so to speak, condemning ourselves to a single provider – hardly anyone will take over such a system and take care of its maintenance or rebuilding. Technology companies then suggest moving to a new system or possibly refactoring the code. This is because when a monolithic system is about to “go” into new hands, it is most often already a legacy system.
Pros and Cons of Microservices Architecture
The biggest disadvantages of monoliths are the biggest advantages of systems based on microservices architecture.
Undoubtedly, high scalability and flexibility to change are huge advantages of the solution of the architecture described above. An additional advantage is also the freedom of choice of technology and the possibility of independent work on individual parts of the system of different unrelated teams.
But like everything in the technical world, microservices also have drawbacks. Communication between individual microservices is the bottleneck. With the high level of complexity of a distributed system, you have to deal with potential errors in the communication of individual services. In addition, it is much more difficult to ensure the principle of transactional in the sense of ACID in such a designed system. Also, the security of the system is something to pay special attention to. Moving communication from internal memory to an internal microservices network can result in potential opportunities for data to be stolen while being transferred between services.
As in the case of classic monolithic applications also in a distributed system based on the microservices architecture, we have a tradeoff for something.
Below is a sample source code repository containing an implementation of a microservices architecture using the event sourcing pattern:
https://github.com/mjaracz/nestjs-microservices-example
Monolithic vs. Microservices Architecture: What to choose?
A monolithic system – as long as you intend to take care of it, of course – can be a good choice for start-ups that don’t have a great need to implement changes quickly and that don’t quite know what they want yet. It can also be a good choice if the system we need is to be relatively small and support a single process.
In these cases, 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 divided into microservices relatively easily later. Likewise, it thus represents a kind of golden mean between a monolith and a distributed system.
However, as our organization grows, the microservices architecture may become advantageous. In particular, if there is a clear separation between some parts of the business domain, it is a sign that these parts can form self-contained services, which can be developed by different teams and scaled independently. Of course, such a choice is always a trade-off and must be well thought out.
Should you have further questions? Get in touch with our team here.
