But it’s a difficult decision to choose the right architecture, therefore it should be carefully planned. And in order to do this, we should be aware of the pros and cons of each solution. It is important not to focus on trends but on the real and objective evaluation of the new system so that we do not get into trouble implementing the novelty at any rate.

Let’s take a closer look at how a microservices approach differs from a monolithic one, where and how to use them, their advantages and benefits.

When can we use microservices architecture?

• when the application is big and modular
  In principle, microservices are supposed to separate functionalities from one another. Each microservice is a single module of the whole system, individually managed and performing a strictly defined task or a small logically connected group of tasks. It communicates with other microservices, resources or external systems. If we are able to logically divide our system into such subsets, we can take microservices into account.
• when we plan frequent changes to the modules
  If we know at the very beginning that the system will be developed or transformed, it is a good reason why we should at least consider using microservices. We will be able to change, improve, or develop each of them separately, without interfering in others.
• when we have the infrastructure
  It is absolutely a prerequisite. It is necessary to focus on the conditions concerning resources and the whole infrastructure and present them to the client before taking any decision on the microservice architecture. The client should be aware of the required conditions concerning resources and the whole infrastructure before choosing the microservice infrastructure.

Benefits of microservices architecture

• rapid response to changes in production
  Each microservice can be implemented without stopping the whole system. Only the new version of the module is updated, step by step substituting all microservices of the module until all of them are in the final version.
• scalability
  Thanks to the division into modules we are able to scale particular microservices if necessary. If a certain functionality is overstuffed, we can increase its resources by multiplying the module data at the same time increasing the productivity. We should bear in mind, however, that scalability does not always work equally well – multiplying the microservice integrating with the external system will not always solve the problem as we will still be dependent on the system.
• failure isolation
  In case of failure in a microservice, we are able to restore it quickly, restart or release a new version with a hotfix. If the module uses a certain resource e.g. data base or the external system in case it is unavailable we can simply switch off the module or the functionality informing the user about the failure or get data from cache. We do not have to wait for the timeout of the resource trying to process the request.

What to consider

When we decided to microservices architecture, we should particularly pay attention to:

• developement
  Each microservice is a single independent application that possesses its own version, configuration, repository, and everything that a monolith actually has. If we have a few, several or dozens such microservices, that means a lot more work in the organization while managing particular modules.
• more difficult refactoring
  Microservices within one system have a number of common features e.g. libraries, security standards or other custom solutions. This means additional and time-consuming work when some changes are to be implemented. Many modules are dependent on one another, so API change in one results in the necessity of changes in others.
• transactions
  In reality we should avoid transactions. If the main task of the system is work on a data base – which usually involves transactions – then monolith is worth considering. Of course it is possible to devote one microservice to data base service, however, if this is the main functionality of the system then it would be pointless in my opinion.
• request efficiency
  We should bear in mind that when using microservices, the efficiency within one request is falling, as the request is passed to other microservices in accordance with their functionalities and the whole system logic. If a monolith was used, the request would be processed faster, as the logic would be placed in the center of one application. On the other hand, the efficiency of the system can be raised thanks to scalability, which in turn can be achieved using the monolith.
• configuration and environment management
  As I mentioned before, much more attention is paid not only to development, but to the management of the whole system, configuration, deployment, monitoring, etc. Of course, efficient microservice environment requires certain tools, eg. Kubernetes to enhance automating and management of the system. However, it is not easy to simply start using these tools quickly and professionally.

As you can see, there is a number of advantages and benefits as well as disadvantages and difficulties. Pretius has considerable experience in both solutions. While planning the architecture of new systems, we carefully analyze all aspects and we present the conclusions and suggestions to our Clients.