Microservices, um contraponto

Hoje no momento, muito se fala de microservices em palestras, eventos, videos, cursos e afins. Empresas altamente admiradas como a Netflix, por exemplo, o têm aplicado, e isso inspira muitos a querer também fazê-lo. Mas aí que mora o perigo.

Entenda o que é

É importante não adotarmos determinado padrão ou tecnologia por moda e sim por uma decisão embasada e sensata. Para isso, o primeiro passo é entender do que isso se trata. No caso de microservices, estamos falando de uma arquitetura de solução orientada a micro serviços, ou seja, serviços muito pequenos, com funções muito específicas que se comunicam entre si. Essa organização trouxe uma série de vantagens porém trouxe a necessidade de que se implementasse algumas técnicas de gerenciamento deles como orquestração e coreografia. Não me aprofundarei muito nesses pontos pois o objetivo desse artigo é na verdade colocar o que pouco se vê por aí: o contraponto, se desprender de paixões e empolgações e discutir as possíveis desvantagens dessa arquitetura.

Qual o seu cenário?

Antes de adotar qualquer arquitetura de solução, sempre sugiro que avalie se ela cabe para o seu cenário pois nenhuma delas é uma bala de prata, que vale para qualquer caso. Dependendo do seu contexto, ela pode atribuir uma complexidade enorme onde não se precisa e talvez você não tenha sequer condições de gerenciar isso ou, se tem, o fará com muita dificuldade.

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 se 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 sem avaliar isso.

Perda de performance

Se o seu sistema tem uma performance crítica, talvez microservices não seja a melhor abordagem, pois como trata-se 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. Dependendo do protocolo utilizado, a perda é ainda maior. Como o número de serviços é alto e a comunicação entre eles é constante, o acumulativo dessa perda pode ter um impacto considerável. Avalie isso.

Implantação mais custosa

Quanto mais serviços você tiver no seu sistema, maior a probabilidade de que 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 por exemplo, ela conter 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 mesmo, 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.

Gerenciamento mais complexo

No âmbito do desenvolvimento em si, 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 a complexidade dela 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? Pense nessas 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 conter operações de persistência, deverá ter o seu próprio banco de dados. Isso se dá pra que se preserve completamente o desacoplamento entre eles.

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 quanto à 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 pra isso? 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, independentemente se você está iniciando do zero uma arquitetura microservices ou migrando um sistema monolítico, é importante estar ciente destes “espinhos”.

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 você tinha por exemplo, um sistema contendo um client e um server exigindo 1 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.

Porém, isso pode 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 esta 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 pra 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 conforme muitos serviços entram no processo. Por exemplo, se numa regra de negócio, eu utilizo o serviço X1 e este 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

Longe de mim ser contra microservices, não é essa a intenção deste post. Não se trata na verdade de ser contra ou de ser a favor, pois eu posso 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. Casos de sucesso comprovam isso. 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.