Microsserviços

Quando pretende-se implantar uma aplicação na nuvem o ideal é que a aplicação seja projetada como uma aplicação nativa para nuvem, e o estilo arquitetural que tem sido usado com êxito é microsserviços. Assim, nesta seção, propõe-se uma definição para microsserviços no contexto de multi-cloud e descreve-se seus princípios e benefícios. Além disso, compara-se microsserviços com arquiteturas tradicionais. Por fim, apresenta-se os principais desafios na adoção de microsserviços.

Na literatura, os microsserviços possuem várias definições. De acordo com Newman (2015), microsserviços são pequenos serviços autônomos que trabalham juntos. Na segunda definição, dada por Pautasso et al. (2017), os microsserviços representam um estilo arquitetônico como uma abordagem para desenvolver uma única aplicação como um conjunto de pequenos serviços, cada um executando seu processo e se comunicando com mecanismos leves, geralmente uma Application Programming Interface (API) de recursos HTTP. Na definição fornecida por

RV (2016), microsserviços são um estilo arquitetural ou uma abordagem para a construção de sistemas de TI como um conjunto de recursos de construção autônomos e fracamente acoplados. Por fim, Dragoni et al. (2017) propuseram duas definições relacionadas a microsserviço: uma para microsserviço em si e outra para arquitetura de microsserviço. Para os autores, um microsserviço é um processo coeso e independente que interage por meio de mensagens, enquanto uma arquitetura de microsserviço é uma aplicação distribuída, em que todos os seus módulos são microsserviços.

Apesar destes conceitos, optou-se neste trabalho por uma definição própria, por entender que é necessário uma visão mais ampla que as definições encontradas até a escrita desta tese. Portanto, neste trabalho define-se Microsserviços como um conjunto de serviços autôno- mos, independentes e autocontidos, nos quais cada serviço tem um único objetivo, representando uma lógica de negócio, e eles devem ser fracamente acoplados e interagem para construir uma aplicação distribuída.

No contexto da definição proposta aqui, um microsserviço necessita de vários ser- viços de nuvem para executar suas tarefas. Além disso, como cada microsserviço representa uma lógica de negócios, entende-se que existe uma comunicação entre os serviços de nuvem utilizado por um microsserviço maior que a comunicação entre dois microsserviços, os quais tratam lógica de negócio distintas.

A fim de construir microsserviços, os princípios de sua arquitetura precisam ser conhecidos. De acordo com RV (2016), os princípios da arquitetura de microsserviços são autonomia e responsabilidade única. Os princípios devem estar presentes no projeto e desenvolvi- mento de microsserviços. O princípio responsabilidade única significa ter total responsabilidade por uma lógica de negócios e sua execução. A autonomia implica que os microsserviços sejam autônomos, independentemente implantáveis.

Além dos princípios faz-se necessário conhecer os benefícios dos microsserviços por trás dos sistemas distribuídos. De acordo com Newman (2015) e RV (2016) existem sete benefícios principais. O primeiro, heterogeneidade da tecnologia, permite decidir qual é a ferramenta mais adequada para cada serviço de uma aplicação composta por múltiplos serviços e com múltipla colaboração. Isto traz uma flexibilidade para projetar soluções com maior custo benefício. A resiliência é outro benefício, permite que um componente do sistema falhe, contanto que não esteja em cascata e permaneça isolado do resto do sistema, que pode continuar funcionando. O terceiro, a escalabilidade, permite expandir somente os serviços que

precisam de redimensionamento, sem alterar os demais serviços. A facilidade de implantação é outro benefício, no qual um microsserviço pode ser implantado independentemente dos outros microsserviços de uma aplicação. Isto permite atualizações e correções apenas de um serviço, bem como implantação rápida. Em relação ao alinhamento organizacional, os microsserviços permitem alinhar melhor a arquitetura à organização, ajudando a minimizar o número de pessoas trabalhando no código. Ele também permite trabalhar com equipes menores distribuídas em vários microsserviços. A composibilidade significa que a funcionalidade pode ser consumida de forma diferente para diferentes propósitos. Por fim, a otimização por substituição significa que é muito mais fácil gerenciar o custo de substituir serviços por uma implantação melhor ou até excluí-los completamente. Desta maneira, torna-se mais fácil atualizar e melhorar serviços em uma aplicação.

Para melhor apresentar o descrito nesta seção, e de acordo com RV (2016) a Figura 9 ilustra a arquitetura de uma aplicação baseada em microsserviços. Através da arquitetura é possível observar que cada microsserviço possui três camadas: apresentação, negócio e banco de dados. Portanto, como cada microsserviço representa uma lógica de negócios, os microsserviços estão alinhados às características de negócios e seus ciclos de vida, os quais podem ser gerenciáveis de maneira independente.

Fonte: RV (2016).

Figura 9. Arquitetura de uma Aplicação baseada em Microsserviços.

A Figura 10 apresenta a arquitetura tradicional de uma aplicação, e observa-se que, diferentemente da arquitetura baseada em microsserviços, todos os módulos representam todas as camadas de negócios, ou seja, cada camada de negócio possui todos os módulos.

Fonte: RV (2016).

Figura 10. Arquitetura de uma Aplicação Tradicional.

Além de comparar as arquiteturas, neste presente trabalho, apresenta-se uma com- paração entre o desenvolvimento monolítico e o baseado em microsserviço em conformidade com RV (2016), a qual é ilustrada pelas Figuras 11a e 11b. O gráfico da Figura 11a compara a agilidade, velocidade de entrega e escala. Pode-se observar que as aplicações baseadas em microsserviços possuem maior agilidade, velocidade de entrega e escala que as aplicações mono- líticas. O gráfico da Figura 11b compara o tempo resposta e o custo. Nota-se que as aplicações baseadas em microsserviços têm menor tempo de resposta e custo do que as aplicações monolíti- cas. Diante deste contexto e das características necessárias para uma aplicação ser distribuída em múltiplos provedores de nuvem, e das características e benefícios constata-se que o estilo arquitetural de microsserviços são adequados para aplicações nativas para múltiplos provedores de nuvem.

Embora existam vários benefícios quanto ao uso de microsserviços, eles possuem alguns desafios. Os principais desafios relacionados à adoção de microsserviços na construção de um sistema são: (i) os arquitetos de softwares devem mudar a maneira de pensar o projeto dos sistemas e devem decidir sobre os limites certos para cada microsserviço que compõe o software; (ii) as complexidades dos sistemas distribuídos; (iii) a necessidade de escalar os sistemas de maneira diferente e garantir que os microsserviços sejam resilientes (NEWMAN, 2015) e (DRAGONI et al., 2017).

(a) Agilidade, Velocidade de Entrega e Escalabilidade.

(b) Custo e Tempo de Resposta.

Figura 11. Uma comparação entre o desenvolvimento tradicional e o baseado em microsserviços.