“Hoje em dia, no que diz respeito à arquitectura de aplicações, é comum ouvir falar do conceito de microsserviços e das suas maravilhas.

Este conceito assenta na ideia de que as várias funcionalidades ou módulos da aplicação devem ser desacopladas em serviços mais pequenos, independentes uns dos outros e que podem comunicar entre si. O que contrasta com a arquitectura monolítica tradicional, em que todas as funcionalidades estão acopladas na mesma camada de negócio e a base de dados é única.

Por exemplo, num website, o histórico de produtos visualizados e a recomendação de produtos podem ser separados em dois serviços independentes, em que este último consultará o serviço de histórico através de protocolos síncronos como HTTP/REST ou assíncronos como AMQP.

Este tipo de organização permite que cada microsserviço tenha um ciclo de vida independente dos demais, o que abre muitas portas. Ora vejamos:

– Flexibilidade de implementação: serviços independentes podem ser implementados em linguagens diferentes;
– Mais fácil para manter: serviços mais pequenos são mais fáceis de compreender, desenvolver e testar;
– Time-to-market menor: serviços independentes podem ser desenvolvidos por equipas diferentes em paralelo;
– Deploys independentes: A actualização de uma funcionalidade apenas requer a indisponibilização e deploy do respectivo microsserviço e não de toda a aplicação;
– Infraestrutura distribuída: os vários serviços podem estar alojados em servidores diferentes;
– Altamente escalável: a adição de uma nova funcionalidade pode ser feita com um serviço novo sem a necessidade de alterar os serviços já existentes;
– Mais resiliente: a falha de um microsserviço apenas indisponibiliza a respectiva funcionalidade em vez de toda a aplicação.

É uma lista grande de vantagens mas não podemos esquecer que, na maioria das vezes, para ganharmos algo, precisamos de comprometer algo também, e aí surgem as desvantagens. No caso dos microsserviços temos uma complexidade inevitavelmente maior face ao monólito, uma vez que se trata de um sistema distribuído. Se nos focarmos na aplicação como um todo, vemos que com microsserviços irá consumir mais memória, o mecanismo de comunicação entre serviços tem de ser implementado e testado e há mais pacotes para fazer deploy, já para não falar no desafio que por vezes é decidir quais os microsserviços que devem existir.

É então recomendável abraçar cegamente este conceito de microsserviços e abandonar de vez o modelo monolítico? Na minha opinião, não. Ambos têm mérito e ambos têm os seus casos de uso. Se a aplicação como um todo for pequena, muitas das vantagens dos microsserviços em relação ao monólito desaparecem e as que ficam deixam de conseguir justificar o acréscimo na complexidade. No entanto, se se tratar, por exemplo, de uma aplicação crítica, que não pode ter indisponibilidade ou uma aplicação com vários módulos que sejam constantemente actualizados, os microserviços são uma abordagem que deve ser seriamente considerada.”

Rafael Mendes 

Backend Developer – Prime Solutions