A modinha do momento se chama microservices. Quando devs ouvem essa palavrinha mágica, os olhos brilham. Cada dia mais, esse tem se tornado um dos assuntos centrais em palestras, eventos, vídeos, cursos e afins.
Empresas altamente admiradas, como a Netflix por exemplo, tem aplicado essa arquitetura, e isso inspira muitos a também querer aplicá-la.
O uso de microservices, porém, não é recomendado para todos. E é aí que mora o perigo. Para ter certeza de que ele se adequa às suas necessidades, o primeiro passo é entender o que exatamente são microservices.
Entenda o que são microservices
O grande perigo de uma modinha é como o uso dos termos se torna uma espécie de “epidemia anônima”, com todos ficando doentes sem saber ao certo o que tem.
O mais comum é ver gente resumindo microservices pura e simplesmente ao conceito de “serviços pequenos”, sem se atentar para temas importantes relacionados a ele como desacoplamento de comportamento e de dados, orquestração e coreografia.
Eu não pretendo abordar estes e outros pontos conceituais sobre microservices pois a internet está recheada de informações sobre. Uma pesquisa rápida te deixará a par disso e também das suas vantagens.
Aqui, eu pretendo apenas abordar alguns pontos que acho importante considerar antes de decidir por essa abordagem, sem romantismo e sem paixões.
>>Leitura Recomendada:
Os principais serviços da arquitetura AWS!
A importância de entender sua arquitetura de software
Não vá pela euforia. E isso vale pra qualquer tecnologia, técnica ou metodologia que esteja sendo a hype do momento.
É muito importante entender as vantagens, as desvantagens e relacionar essas informações com o seu cenário atual para saber o que é mais adequado. E muitas vezes microservices não são. Daí vários problemas tendem a ocorrer, mas reverter o que foi feito se torna complicado ou até inviável.
Não deixe pra encontrar o Godzilla somente quando ele já invadiu a cidade. Evite esse tipo de problema avaliando a real necessidade de se usar microservices dentro do seu contexto.
>>Leitura Recomendada:
Tudo o que você precisa saber sobre o Spring Boot
Analise alguns riscos, oportunidades, vantagens e desvantagens antes de começar a usar microservices:
Microservices é uma arquitetura mais complexa
Em uma aplicação monolítica, é uma boa prática utilizar padrões e conceitos de modelagem e arquitetura de software, como por exemplo DDD, especialmente Bounded Contexts, de forma que o escopo de seus objetos esteja bem separado, conforme as responsabilidades do seu sistema.
Já em uma aplicação de microservices, isso deixou de ser uma boa prática e passou a ser obrigatoriedade. Se você não tratar a coisa dessa forma, correrá um sério risco de ter bastante retrabalho ou muito código ocioso em seus serviços.
Logo, usar microservices implica maior responsabilidade e exigência técnica, mas muitos não se atentam a isso pois saem aplicando o conceito por pura euforia.
Perda de performance no software
Se o seu sistema tem uma performance crítica, talvez microservices não seja a melhor abordagem.
Como se trata de uma abordagem fundada na criação e/ou decomposição de muitos serviços pequenos que se comunicam utilizando algum protocolo, como HTTP por exemplo, isso faz com que, dependendo de como forem separadas as responsabilidades, o que antes seria a execução de um código incorporado no mesmo assembly, se tornará uma chamada de um serviço.
Isso afeta significativamente a performance, pois um código invocado em um mesmo assembly sempre será consideravelmente mais rápido, principalmente se o protocolo de comunicação escolhido não for dos mais rápidos (como é o próprio HTTP).
Assim, parta da premissa de que uma abordagem microservices deverá implicar em perda de performance.
Obviamente que, dependendo do contexto, isso pode ser tolerado ou até contornado, com alguma compensação ou não, mas esse fato deve ser reconhecido e pesado devidamente na tomada de decisões do projeto.
>>Leitura Recomendada:
Bitbucket vs GitHub: quem vence a batalha?
Implantação de microservices pode ser mais custosa
Quanto mais serviços você tiver no seu sistema, maior a probabilidade de o deploy dele ser custoso.
Ao utilizar microservices, nós ganhamos a vantagem de ter uma maior independência e desacoplamento das partes do sistema, mas em contrapartida, temos mais serviços para publicar e configurar.
Logicamente que esse problema pode ser minimizado dependendo da sua política de publicação. Se ela, por exemplo, contiver um processo automatizado de integração contínua para a geração dos builds e publicação, esses efeitos colaterais serão minimizados.
Porém, há circunstâncias que dificultam isso, como a falta de infraestrutura ou até alguns aspectos próprios da solução em si. Como no caso dela ser on premise, por exemplo.
E aí, como proceder em casos desse tipo? Vale a pena investir nessa arquitetura mesmo assim? Você pode decidir isso ou depende de decisões do cliente? Todas essas questões devem ser consideradas.
Usar microservices traz um gerenciamento mais complexo
No âmbito do desenvolvimento, uma das principais vantagens de microservices é permitir uma manutenção mais simples e rápida do código, por deixá-lo com um alto desacoplamento e focado em um contexto específico do negócio. Afinal, troubleshootings são mais facilmente aplicados em pequenos sistemas.
Porém, quanto à gestão do software, essa abordagem tende a aumentar consideravelmente sua complexidade em virtude da quantidade excessiva de serviços. Em suma, microservices favorece a manutenção do código, mas não do software.
Assim, quando analisar a possibilidade de adotar microservices, seja na criação ou na migração de um sistema, pense no gerenciamento dele, considerando o ambiente em que ele estará rodando e a equipe que cuidará dele.
Que aspectos do ambiente podem tornar a gestão do software mais complexa? A equipe que manterá o sistema é capaz de suportá-lo, tanto em conhecimento quanto em carga de trabalho?
Considere essas questões e formule uma estratégia que pense à frente, não só na entrega do sistema agora, mas em como mantê-lo futuramente.
Gerenciamento de dados e transações
Em uma abordagem microservices ideal, cada serviço, se contiver operações de persistência, deverá ter o seu próprio banco de dados. Isso se dá para que o desacoplamento entre eles seja completamente preservado.
Porém, sabemos que no mundo real é muito difícil modelar o sistema dessa forma e, se for modelado, manter as N bases para os N serviços pode se tornar uma tarefa monstruosa, não só nos aspectos relacionados ao desenvolvimento, mas também à gestão (DBAs que o digam).
Além disso, pelo fato dos dados estarem desagregados e em bases separadas, pode se tornar muito difícil aplicar consultas complexas para análise deles. Talvez você tenha que considerar duplicar dados, salvando cópias em uma base de relatórios, por exemplo.
Mas e o espaço em disco disponível? É suficiente? Como isso será gerido? Estas e outras questões precisam ser levadas em conta.
Outro ponto importante e que exigirá maior capacitação técnica é: como lidar com transações? Se você estiver migrando um sistema transacional monolítico para uma abordagem microservices, o trabalho será maior ainda, pois uma transação que hoje abre e fecha em um monólito terá que ser fragmentada, sendo aberta em um serviço e finalizada em outro, já que agora aquele trecho de código foi distribuído entre eles.
Ou seja, mudanças nessas rotinas serão necessárias. Há padrões voltados à resolução deste tipo de problema, mas eles devem ser analisados com prudência quanto à adequação ao cenário.
De qualquer forma, independente de você estar iniciando do zero uma arquitetura microservices ou migrando um sistema monolítico, é importante estar ciente desses “espinhos”.
>>Leitura Recomendada:
Kubernetes: a arquitetura de um cluster
Excesso de requisições
O conceito de microservices aumenta exponencialmente o número de requisições – ou chamadas de serviço – executadas pelo sistema.
Numa migração se, por exemplo, você tinha um sistema contendo um client e um server exigindo uma requisição para executar uma regra de negócio, em um sistema com uma arquitetura microservices, essa mesma regra, dependendo de sua complexidade, pode passar por dezenas de serviços para ter sua execução finalizada. Ou seja, passamos de 1 para N requisições. Um aumento considerável.
Isso pode, porém, aumentar mais ainda. Por determinados trechos de código estarem disponíveis em serviços, existe a possibilidade deles serem chamados por mais de um sistema ao mesmo tempo, ou seja, abrimos um cenário de concorrência que antes poderia não existir.
E nestes possíveis cenários, as requisições aumentariam exponencialmente. A sua infraestrutura está preparada para isso? Como ela se comportaria com uma demanda maior e concorrente de execução de regras? São preocupações que agora surgem.
Pontos de falha
Comparado a um sistema monolítico, os pontos de falha mudarão em uma abordagem microservices, pois o mindset é outro. Você terá que mapeá-los e criar planos de contingência para eles.
Tomando o mesmo exemplo citado acima, considere um sistema que toma diversos passos para executar uma regra de negócio. Em uma aplicação microservices, esses passos se tornariam serviços.
E se por acaso um deles cair, como será o comportamento da aplicação? Haverão alarmes falsos? Há uma contingência? Isso causará inconsistência de dados?
Essas preocupações provavelmente não existiriam se essa regra pertencesse a um sistema monolítico, mas quando você transporta isso para uma abordagem microservices, você passa a ter novas preocupações que, se não forem consideradas, afetarão o negócio.
Muitos pontos de brecha poderão impactar consideravelmente requisitos não funcionais.
Por exemplo, na migração de um sistema monolítico para microservices, considere a questão das requisições envolvidas na execução de uma regra de negócio. O que antes era código incorporado se tornou chamada a um serviço.
Como uma maior latência no tempo de resposta deste serviço afetará a eficácia do sistema em executar essa regra de negócio? Ele manterá os tempos em valores aceitáveis?
No caso de um sistema arquitetado do zero, os tempos atenderão aos requisitos do cliente? Como fazer com que atendam? Se estes pontos não forem considerados, microservices podem mais atrapalhar que ajudar.
Disponibilidade
Dependendo de como está estruturada a sua arquitetura microservices, a disponibilidade de seu sistema pode diminuir, logo este é um ponto de atenção a se considerar, analisar e, se for o caso, formular uma estratégia para contornar.
Uma regra de negócio em uma arquitetura de microservices tende a ter diversas chamadas encadeadas entre os serviços, ou seja, se em um monólito um serviço X irá executar uma regra de negócio, em uma arquitetura microservices a mesma regra de negócio poderá ser executada pelos serviços X1, X2, X3…. XN, onde X1 chama X2, que chama X3 e assim por diante.
Agora considere que o serviço X, monolítico, tinha uma disponibilidade de 99%, ou seja, ele está disponível em 99% do tempo de operação em produção. Numa arquitetura microservices, essa disponibilidade irá decair em decorrência dos muitos serviços que entram no processo.
Por exemplo, se numa regra de negócio eu utilizo o serviço X1 e esse chama X2 para completá-la, teremos uma disponibilidade de 98% e não mais 99%.
Isso ocorre pelo fato de que as possíveis causas de uma indisponibilidade de X1 ocorrerão também em X2, porém de forma independente, ou seja, o fato de X1 estar disponível não garante necessariamente que X2 também esteja.
Conclusão: usar microservices ou não?
Longe de mim ser contra microservices, não é essa a intenção desse post. Não se trata, na verdade, de ser contra ou de ser a favor, pois é possível ser os dois, dependendo da situação.
É maravilhoso ter cada vez mais abordagens novas de arquitetura surgindo e, no caso de microservices, está mais do que comprovado que há benefícios, e muitos!
Porém, ele pode ter sérios efeitos colaterais se não for usado com senso crítico e prudência. A intenção do post foi justamente conscientizar o leitor disso ao alistar alguns dos pontos de atenção que considero importante.
Resumindo: não há bala de prata. É sempre importante ter prudência e análise crítica ao se conhecer novas técnicas, arquiteturas ou tecnologias. E microservices pode ser realmente algo sensacional, se você fizer isso.
Artigo original retirado do site tecnificando e postado com autorização do autor.
