Seriam os microsserviços a melhor opção para projetos ?
  Os microsserviços estão em voga, possuem o seu mérito, mas seriam realmente a melhor opção para o desenvolvimento de projetos ?


Vamos iniciar apresentando o que são microsserviços para quem esta chegando agora.
 


 

Antes de começar a verificar se a arquitetura de microsserviços é a melhor opção para o seu projeto, tentaremos entender o que são microsserviços.

 

Se você acha que escrever o código e expô-lo como o serviço REST é um microsserviço, seu entendimento não esta correto, pois, nem toda API REST é um microsserviço.

Podemos dizer que na indústria de software existem três tipos mais usados de arquiteturas.

  1. Arquitetura de monolíto ou monolítica

  2. SOA

  3. Microsserviços

Na década passada, os anos 2000, os aplicativos corporativos foram desenvolvidos usando arquitetura monolítica. Todos os objetos de UI, lógica de negócios e acesso aos dados residiam em um único servidor. Todo o código presente neste servidor costumava se comunicar com o banco de dados. Não havia modularidade ou fraco acoplamento.

A SOA ou arquitetura orientada a serviços foi construída principalmente dividindo a lógica entre vários serviços. Isso ajudaria outros aplicativos a usar a mesma lógica, se necessário. Não era fortemente acoplado a uma única aplicação. O serviço pode ser implantado em servidores diferentes em comparação com o código de acesso a dados ou o código da interface do usuário. Nesse tipo de arquitetura, a interface do usuário não se comunicaria diretamente com os serviços, mas sim interagiria usando uma URL de proxy fornecida por ferramentas como o barramento de serviço corporativo.

 

Os microsserviços são a evolução mais recente da maneira como os aplicativos interagem com os bancos de dados. Na arquitetura Monolítica ou SOA mesmo para uma única mudança temos que fazer um release inteiro, o que causaria desperdício de tempo e recursos. Na arquitetura de microsserviços, todos os componentes de negócios são divididos em pequenos serviços separados. Isso ajuda a reduzir o tempo de implantação, além disso, esses serviços são facilmente escaláveis.

 

 

 

Vantagens dos microsserviços


1- São pequenos

Como o nome sugere, estes são pequenos e facilmente compreensíveis pedaços de código. Mas como decidiria, quão pequeno é pequeno? A resposta é , se você perder o código do microsserviço ou jogá-lo em algum lugar e puder reescrevê-lo em alguns dias ou em uma semana ou duas. Você tem um microsserviço.

2- Focam em uma tarefa

Isso está realmente relacionado à separação de interesses no domínio do problema. Se você estiver manipulando e fazendo várias coisas em seu serviço, isso não é um candidato para microsserviço. Ele faz uma tarefa quando visto de fora. Aqui os módulos não são acoplados entre si. Recursos individuais podem ser liberados e implantados sem perturbar ou testar outros módulos.

3- São Autônomos

As equipes que estão trabalhando em um microsserviço específico podem trabalhar separadamente sem colaborar com outras equipes. A equipe pode alterar a implementação do serviço sem coordenação com mais ninguém.

4- Podem ser implantados de forma independente

A capacidade de implantação é uma das características desses serviços que os tornam altamente úteis. Como uma equipe trabalhando em um recurso do projeto, não precisa ser dependente da outra equipe, pois nenhuma das funcionalidades se cruzam.

As equipes podem decidir independentemente quando implantar cada parte do serviço.

Se você precisar testar seu serviço com outros serviços, não é um microsserviço. Devemos ser capazes de construir, testar e implantar o microsserviço de forma independente.

 5. Possuem escalabilidade 

Com microsserviços, cada serviço pode escalar independentemente para atender uma demanda.  

Desvantagens dos microsserviços

1- Complexidade

Os microsserviços são altamente complexos devido à sua natureza dispersa. Precisamos manter vários sistemas para cada serviço. Estes são ideais para grandes equipes. Essas equipes podem cuidar individualmente desses sistemas.

2- Sobrecarga de infraestrutura

Há uma enorme sobrecarga de infraestrutura para manter esses serviços. Como precisamos implantar todos eles nos contêineres individuais.


3- Preocupações com segurança

Na arquitetura monolítica e SOA temos que nos preocupar com apenas um sistema. Mas esse não é o caso do microsserviço e fica mais fácil ter brechas de segurança nessa arquitetura.

 

4. Integração com aplicações monolíticas legadas 

Como não se comunica com outros serviços, o uso da rede em um monolito é bem menor. Esse baixo tráfego de rede é uma vantagem que pode se perder na migração para microsserviços.  

Fazendo algumas considerações

Assim considerando os prós e os contras observe que a maioria das empresas que tiveram sucesso com microsserviços não começou com eles.

Considere os exemplos do Airbnb e do Twitter, que seguiram a rota dos microsserviços depois de superar seus monólitos e agora estão lutando contra suas complexidades. Mesmo empresas de sucesso que usam microsserviços parecem ainda estar descobrindo a melhor maneira de fazê-los funcionar. É evidente que os microsserviços vêm com sua parcela de compensações mas ela tem os seus problemas também.

Pensou em migrar para microsserviços ?

Considere que migrar de um monolito para microsserviços também não é uma tarefa simples, e criar um produto não testado como um novo microsserviço é ainda mais complicado. Os microsserviços só devem ser seriamente considerados após avaliar os caminhos alternativos.

Veja o que observou Martin Fowler sobre usar microsserviços :

1. Quase todas as histórias de microsserviços de sucesso começaram com um monólito que ficou muito grande e foi quebrado.

2. Quase todos os casos em que um sistema que foi construído como um sistema de microsserviço do zero acabou em sérios problemas.

Esse padrão levou muitos a argumentar que você não deve iniciar um novo projeto com microsserviços, mesmo que tenha certeza de que seu aplicativo será grande o suficiente para valer a pena.

O primeiro design raramente é totalmente otimizado. As primeiras iterações de qualquer novo produto são gastas encontrando o que os usuários realmente precisam. Portanto, o sucesso depende de permanecer ágil e ser capaz de melhorar, redesenhar e refatorar rapidamente.

A este respeito, os microsserviços são manifestamente piores do que um monólito. Se você não acertar no design inicial, terá um começo difícil, pois é muito mais difícil refatorar um microsserviço do que um monólito.

Cada software tem um ciclo de vida e podemos ficar tentados a descartar um monólito porque ele é antigo e tem sua parcela de complicações. Mas jogar fora um produto que funciona é um desperdício. Com um pouco de esforço, você poderá extrair mais alguns bons anos do seu sistema atual.

Há dois momentos em que pode parecer que os microsserviços são o único caminho a seguir:

  1. Base de código emaranhada: é difícil fazer alterações e adicionar recursos sem quebrar outras funcionalidades.
  2. Desempenho: você está tendo problemas para dimensionar o monólito.

Uma razão comum pela qual os desenvolvedores desejam evitar monólitos é sua propensão a se deteriorar em um emaranhado de código. É um desafio adicionar novos recursos quando chegamos a esse ponto, pois tudo está interconectado.

Mas um monólito não precisa ser uma bagunça e podemos optar pela modularização do monolíto.

A modularização dá muito trabalho, é verdade. Mas também agrega muito valor porque torna o desenvolvimento mais simples. Novos desenvolvedores não precisam conhecer todo o aplicativo antes de começar a fazer alterações. Eles só precisam estar familiarizados com um módulo de cada vez. A modularidade faz um grande monólito parecer pequeno.

A modularização é uma etapa necessária antes da transição para microsserviços e pode ser uma solução melhor do que microsserviços. O monólito modular, como nos microsserviços, resolve o problema da base de código emaranhada dividindo o código em módulos independentes. Ao contrário dos microsserviços, em que a comunicação ocorre em uma rede, os módulos no monólito se comunicam por meio de chamadas de API internas.

A pilha de arquitetura e tecnologia determinará como o monólito pode ser otimizado; um processo que quase invariavelmente começará com modularização e pode alavancar tecnologias de nuvem para dimensionamento como:

Podemos resumir toda essa discussão sobre a transição para microsserviços em uma frase: não faça isso a menos que tenha um bom motivo. As empresas que embarcam na jornada para microsserviços despreparadas e sem um design sólido terão um tempo muito difícil. Você precisa atingir uma massa crítica de cultura de engenharia e conhecimento de dimensionamento antes que os microsserviços sejam considerados uma opção.

Enquanto isso, por que mudar se o seu sistema está funcionando bem e você ainda está desenvolvendo recursos em um ritmo decente?

Assim estes argumentos não tem o objetivo de desencorajá-lo a usar microsserviços mas a pensar bem e ter muita cautela para não embargar na onda para mostrar que seu sistema esta atualizado.

E estamos conversados  ... 

"E é evidente que pela lei ninguém será justificado diante de Deus, porque o justo viverá pela fé."
 Gálatas 3:11

Referências:

José Carlos Macoratti