Quais as desvantagens de adotar microserviços?
Com certeza você já ouviu falar de microserviços. É bem provável que sua empresa implemente em breve, ou já utiliza há um certo tempo. De repente, pode até estar começando, e você pode até ficar um pouco perdido, com essa mudança toda.
Foi então que decidi escrever este post para você, para dar uma noção geral desta arquitetura.
Se você está começando agora, e olha para microserviços com um olhar inovador, deve pensar: cara, isso é muito bom, vou colocar tudo em microserviços. Por outro lado, existe toda uma adaptação que ocorre nesta migração de aplicações monolíticas para aplicações com abordagem em microserviços, novos conceitos e novos nomes, e fora a mudança de como gerenciar ou se adaptar a isso. Sugiro cautela e inovação juntos.
“cara, isso é muito bom,
vou colocar tudo em microserviços”
Algumas vantagens ao optar por microsserviços estão na sua flexibilidade, facilidade na substituição e deploys, serviço independente ou baixo acoplamento, orientado a mensagem, e sem dúvida algo que muito marcante é a possibilidade de escalar um microsserviço sem ter que levar toda a aplicação. Se você é novo nisso, a forma de alcançar esta escalabilidade é usar serviços me cloud em conjunto com técnicas DevOps.
Apenas explorando a questão das vantagens, imagine um e-commerce, onde as partes críticas são as campanhas de marketing e o carrinho de compras/checkout. Não há a necessidade de levar a família toda, apenas estes dois serviços. Se de repente precisar melhorar a escalabilidade de algum serviço que também está sendo exigindo, basta colocar o microsserviço para escalar. Escalar neste caso, seria a publicação deste serviço em diversos servidores ou conteiners, como docker por exemplo. Em um horário de pico, ou datas especiais como Black Friday, o serviço escalaria, ou seja, novas instâncias do serviço são criados automaticamente para atender a alta demanda. Da mesma forma, quando a demanda for baixa, como madrugadas por exemplo, essas instâncias seriam desligadas para reduzir o gasto desnecessário.
E não dá para não pensar em desvantagens, consegue imaginar alguma? Começando pelas mais fáceis, como você faz o debug desta arquitetura? E a latência de rede, que é algo bem estabelecido em aplicações monolíticas? E sobre o conhecimento da equipe, já pensou que cada microsserviço poderia ser escrito em uma linguagem ou tecnologia diferente? Como você lida com problemas de conexão? E a segurança disso tudo? Parecia tudo muito lindo mesmo. Para cada uma destas questões, existem frameworks e tecnologias para resolvê-las, mas são necessários alguns livros para falar delas, mas fica para que você pense como vai lidar com isso.
“Começando pelas mais fáceis,
como
você faz o debug desta arquitetura?”
Acontece que na prática, para adotar microsserviços é preciso adotar um novo mindset, explorar novas possibilidades e estar disposto a lidar com questões que às vezes estão respondidas apenas parcialmente. A cultura da empresa tem que ser adaptada também. É muito dinâmico, e a situação requer bom senso de todos.
Agora, eu gostaria de falar de um problema mais específico que você pode enfrentar. Como você faz para ter dados íntegros entre os diferentes módulos, sendo que eles estão executando em um contexto separado? Como possíveis erros de comunicação, é preciso algo que una tudo isso, ou que ajude ao invés de atrapalhar e que evite ao máximo este tipo de situação. Acredito que ninguém gosta quando uma compra não finaliza, imagine do lado do vendedor, em que a venda não finaliza, todos saem insatisfeitos.
Para que você pense um pouco antes da solução, que tal chamar cada serviço e colocar uma flag de não concluído, e depois que você passar em todos os pontos do processo, alterar esta flag para concluído? Neste caso, se um dos serviços falhar, ele não fica efetivado e o programa que iniciou o processo poderá executar tudo de novo. Esta seria uma AOG, arquitetura orientada a gambiarra. Agora sério, que tal se você colocar todas as ações necessárias do processo em uma lista, e cada serviço sendo responsável por um item da lista, sendo esta ferramenta controlando quais itens foram executados e quais não foram? Aí sim, estamos falando em algo mais coerente. Qual seria então esta ferramenta?
“Esta seria uma AOG, arquitetura
orientada a gambiarra”
Se você já está por dentro, esta primeira ferramenta seria o serviço de mensagens, como por exemplo o Rabbit MQ, IBM MQ, Kafka, AWS SQS, entre outros, que irão dominar tudo relacionado a troca de mensagens entre os diversos microsserviços. Se uma mensagem foi lida, armazenar a resposta, estar disponível para todos os serviços. A aplicação para isso são diversas. A troca de mensagens entre sistemas é a base de tudo, e um serviço de mensagens é perfeito para tratar das adversidades atreladas a arquitetura de microsserviços. Para adicionar um controle ainda maior, podemos colocar uma ferramenta de integração mais poderosa como o IBM Integration Bus.
O IBM Integration Bus é uma ferramenta poderosa, capaz de se conectar com serviços diversos de mensageria, fornecer serviços REST, se comunicar com banco de dados, transformar mensagens, unificar o padrão de troca de mensagens entre as diversas plataformas, e tem se transformado constantemente para acompanhar e agregar muito na arquitetura de microsserviços, incluindo a execução do IIB em containers docker e instalação simples de basicamente copiar e colar os binários e colocar para rodar. Aprender o IIB é algo que vai trazer novas possibilidades e agregar na visão para arquitetar e manter a estrutura em microsserviços. E se você ainda está pensando, ele também atende muito bem as aplicações monolíticas servindo como um ESB central para a empresa, mas aí é assunto para um outro post.
About Post Author
