Micro-serviços – Quando optar por esta arquitetura?

Uma das discussões mais quentes nos grupos de Arquitetura de Software é quando deve-se optar por uma Arquitetura do tipo Micro-serviços.

Antes de iniciarmos essa discussão vamos a terminologia.

Micro-serviços é um estilo arquitetural no qual uma aplicação é composta por diversos serviços reutilizáveis. Cada um deles pode comunicar com outros através de protocolos como HTTP, REST e SOAP. Essa proposta se assemelha bastante ao SOA porém é muito diferente do estilo mais comum que é o Monolíto.

Um Monolíto é um sistema do qual é composto por apenas uma unidade implantável. Ou seja, o sistema é representado por um artefato, seja ele um ‘.ear’, ‘.jar’, ‘zip’, ‘.tar.gz’ ou ‘.egg’. Nesse pacote estão contidos todas classes, arquivos e configurações necessárias para que uma aplicação seja executada.

Agora já podemos fazer a primeira comparação entre os dois estilos. No primeiro temos vários artefatos para serem implantados (representando cada serviço). No segundo, temos somente um pacote para ser promovido para a produção (a aplicação). Então, levando em consideração a máxima de que ‘O simples é lindo’, porque não optar sempre por Monolítos?

Os componentes internos de um Monolíto tendem a serem mais acoplados entre si. Então, a troca de uma implementação (por exemplo, não usaremos mais o serviço de pagamento Paypal e sim o Pague Seguro) pode ser bem mais difícil. Também, caso seja necessário reutilizar algo que já tenha sido construído no Monolíto será uma tarefa mais complexa.

Micro-serviços por sua vez é um estilo arquitetural que promove o baixo acoplamento e a alta coesão. Ou seja, cada micro-serviço implementa uma interface bem definida e possuem um escopo pequeno o suficiente para serem isolados em uma única unidade física. Assim, várias aplicações podem reutilizá-los. E, também, caso seja necessário trocar um componente por outro, essa necessidade é atendida de forma mais simples.

Então, porque não utilizar sempre Micro-serviços? A primeira regra para criar objetos distribuídos é: Não distribua seus objetos! [1] [2]

A distribuição aumentará a complexidade da sua arquitetura. Isso porque você terá mais configuração, mais artefatos para serem implantados, lidará com chamadas remotas (o que acontece se o sistema não estiver no ar? Rede lentas e com falhas? Piora de desempenho?), se utilizar transações elas terão que serem distribuídas [3]. Esses são alguns dos problemas quando é escolhida a distribuição do sistema.

Para concluir, a reposta para decisão ou não de um determinado estilo arquitetural mais uma vez será depende. Vejo que Micro-serviços é um estilo interessante quando existe a necessidade em desenvolver várias aplicações que compartilharão alguns serviços. Isso se encaixa bem em cenários corporativos como bancos, indústrias e grandes empresas que querem construir sistemas para controlar os seus processos de negócio. Já para Startups que querem construir um produto acredito que o mais interessante seja começar simples, mas sempre mantendo o foco em padrões de projeto e não se esquecendo de acoplamento e coesão, utilizando o estilo Monolíto. Por fim, isso tudo não significa que existam casos em que Startups criaram produtos de sucesso utilizando Micro-serviços ou que grandes empresas não conseguirão criar bons sistemas Monolítos.

 

Não se esqueça de deixar aqui os seus pensamentos a respeito desse assunto.

Referências

[1] Martin Fowler – FirstLaw

[2] Martin Fowler – Errant Architectures

Veja Mais em:

[3] Wikipedia – Two-phase commit protocol

[4] Martin Fowler – Microservices

 

 

 

 

 

 

 

Bruno Carneiro

Bruno Carneiro é um apaixonado por TI, pela Engenharia e Arquitetura de Sistemas e pela criação de novos produtos baseados em tecnologia de informação. Formado em Ciência da Computação e pós graduado em Arquiteutra de Sistemas Distribuídos pela PUC-MG. Há mais de sete anos trabalha com desenvolvimento de sistemas que utilizam tecnologias de ponta.

More Posts - Website

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios são marcados com *