“Nowadays, when it comes to applications architecture, it is common to hear about the concept of microservices and its wonders.

This concept is based on the idea that the various functionalities or modules of the application should be decoupled into smaller services that are independent of each other and can communicate with each other. This contrasts with traditional monolithic architecture, where all functionalities are coupled in the same business layer and the database is unique.

For example, on a website, the viewed products history and the product recommendation can be separated into two independent services, where the latter will consult the history service via synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP.

This type of organization allows each microservice to have a life cycle independent of the others, which opens many doors. Let’s see:

– Flexibility of implementation: independent services can be implemented in different languages;

– Easier to maintain: smaller services are easier to understand, develop and test;

– Smaller time-to-market: independent services can be developed by different teams simultaneously;

– Independent deploys: The update of a functionality only requires the unavailability and deployment of the respective microservice and not the entire application;

– Distributed infrastructure: the various services can be hosted on different servers;

– Highly scalable: the addition of a new functionality can be done with a new service without the need to change existing services;

– More resilient: the failure of a microservice only makes its functionality unavailable instead of the entire application.

It is a long list of advantages but we must not forget that, most of the time, in order to gain something, we need to compromise something as well, and then the disadvantages arise. In the case of microservices we inevitably have a greater complexity compared to the monolith, since it is a distributed system. If we focus on the application as a whole, we see that with microservices it will consume more memory, the mechanism of communication between services has to be implemented and tested, and there are more packages to deploy, not to mention the challenge that is sometimes to decide which microservices should exist.

Is it then advisable to blindly embrace this concept of microservices and abandon the monolithic model for good? In my opinion, no. Both have merit and both have their cases of use. If the application as a whole is small, many of the advantages of the microservices in relation to the monolith disappear and those that remain can no longer justify the increase in complexity. However, if it is, for example, a critical application that cannot be unavailable or an application with several modules that are constantly updated, microservices are an approach that must be seriously considered.”

Rafael Mendes

Backend Developer – Prime Solutions