Na área de TI, a fronteira do conhecimento está sempre evoluindo. Em um ciclo virtuoso, a tecnologia consegue nos permitir criar novas soluções, e essas novas soluções geram demanda por novas capacidades tecnológicas. Um dos assuntos do momento, que aparece cheio de potencial, são as arquiteturas de microsserviços. Neste artigo, vamos explorar um pouco o que são essas arquiteturas e a sua aplicação para os negócios. Aplicações monolíticas
Com as tecnologias mais antigas, o padrão arquitetural era a construção de uma aplicação única, grande e ‘completa’. Uma única aplicação tratava de todas as funcionalidades necessárias para um determinado domínio, por exemplo, sistema de gestão, de CRM, ou de força de vendas. Além disso, essa aplicação única era responsável por todas as camadas da solução – ela continha desde a exibição das informações para o usuário em tela (front-end), o processamento das informações (back-end), até o armazenamento (banco de dados). Ex: Sistema de CRM em arquitetura de monólito.
Por que aplicações monolíticas podem ser ruins?
Vamos discutir agora as duas principais dores de conviver com um monólito que afetam diretamente os negócios: escalabilidade e manutenibilidade. Escalabilidade
A escalabilidade é a capacidade de acompanhar o crescimento da demanda. Assim, esse só vai ser um problema se seu negócio estiver crescendo, e nós torcemos que sim. Conforme a empresa cresce, ou atinge um número maior de clientes, é normal sentir impactos no desempenho da aplicação, ou mesmo começar a vivenciar situações de indisponibilidade – aplicações que ‘caem’ ou param de responder para os usuários. Aplicações monolíticas têm facilidade de escala vertical, que consiste, de maneira simplificada, em aumentarmos a capacidade do servidor onde está a aplicação. Então aumentamos a memória, o número de CPUs e torcemos para que seja suficiente. Felizmente, hoje temos soluções de cloud muito mais elásticas – ou seja, maior facilidade para aumentar a capacidade do servidor sem precisar de um processo longo de aquisição e configuração. Mas mesmo assim, todo servidor tem um limite, e não é raro encontrar empresas que já levaram seus monólitos até o limite da máquina. Ex: Cenário de escalabildade vertical.
A outra alternativa é a escalabilidade horizontal – poder dividir a carga entre múltiplos servidores. Porém a arquitetura dos monólitos não é amigável à escalabilidade horizontal. Geralmente, por ser tão intricado, o monólito não permite executar atividades em paralelo e de forma independente, exigindo que os processos sejam executados de forma sequencial, um processo de cada vez, e com toda a aplicação mantendo o ‘estado’ daquele processo específico que está em execução. Assim, os monólitos tem um impacto direto nos negócios, trazendo problemas de desempenho que podem gerar perda de receita, de eficiência operacional ou impactos negativos na imagem da empresa e no relacionamento com os clientes. Além disso, esses problemas de desempenho não são fáceis de resolver e podem se tornar um gargalo, um limite para a capacidade de crescimento da empresa. Ex: Cenário de escalabilidade horizontal.
Manutenibilidade
O outro impacto doloroso dos monólitos está na capacidade de manter a aplicação. O custo de propriedade de um software vai muito além da sua aquisição ou desenvolvimento inicial. A empresa precisa manter a aplicação fazendo manutenção evolutiva, corretiva e ainda garantindo sua disponibilidade através do monitoramento e manutenção do ambiente e infraestrutura associados. O que geralmente acontece é que as aplicações monolíticas são excepcionalmente simples de manter no início. A base de código (code base) é pequena, tudo está no mesmo lugar, é fácil fazer uma correção ou adicionar uma função. Mas, com o tempo, a base de código começa a aumentar, e o número de pessoas envolvidas também. Como tudo está junto, nem todos os desenvolvedores vão ‘colocar as coisas no lugar certo’, e de repente regras de negócio que deveriam estar na camada de back-end são criadas no front-end, ou a função que pertencem a uma funcionalidade X é escrita junto com a da funcionalidade Y. Todos os desenvolvedores – cada um com uma tarefa e um objetivo diferente – estão modificando essa mesma base de código, então é fácil de imaginar que eventualmente eles vão fazer alterações inconsistentes entre si, e acabar criando novos erros não previstos. O efeito dessa dificuldade nos negócios aparece de diferentes maneiras. Uma delas é quando uma nova versão que modificou uma parte específica da aplicação apresenta erros em outras partes que, a princípio, não foram modificadas. Outro efeito é o lead time longo, cada manutenção passa a demandar muito mais tempo na integração entre os desenvolvedores e nos testes, num crescimento exponencial da complexidade de manutenção. Serviços e microsserviços
A solução para esses problemas é segmentar e desacoplar. Criar aplicações em pedaços menores, independentes e com responsabilidades claras, que conversam entre si. Assim vale desacoplar as camadas, uma tendência que já existia em padrões de arquitetura como MVC e MVVM, mas também desacoplar as funções, criando assim múltiplos serviços. Um serviço é um sistema fechado, distinto, que fornece funcionalidade de negócios para apoiar a construção de um ou mais produtos maiores. (Lee Atchison, Architecting for Scale)
O que identifica um serviço são as seguintes características: – Base de código separada; – Dados separados: apenas o próprio serviço gerencia seus dados, sem compartilhamento de estado com outros serviços; – Provê capacidades para outros serviços; – Consome capacidades de outros serviços; Considerando que essas características sejam atendidas, muitos autores usam os termos ‘Serviços’ e ‘Microsserviços‘ como sinônimos. Outros autores indicam que o termo microsserviços se refere à tendência de reduzir cada vez mais o tamanho e as responsabilidades dos serviços, tornando-os mais e mais granulares. Na imagem abaixo, por exemplo, cada principal função foi dividida em um Serviço que contém o seu próprio banco de dados e seu back-end com múltiplos endpoints relacionados àquele domínio. É interessante comentar também que nesse tipo de arquitetura, o próprio front-end também pode ser quebrado, com uma estratégia de microfrontends, e caso seus serviços sejam muito granulares uma camada intermediaria de back-end (o BFF- Backend For Frontend) pode ser útil também. Ex: Sistema de CRM em arquitetura de serviços.
Vantagens e desvantagens
As vantagens de construir uma aplicação baseada em serviços incluem: 1. Decisão granular: como cada parte é independente, é possível tomar decisões também mais independentes. Por exemplo, é possível aplicar diferentes tecnologias de acordo com o desafio de cada parte da aplicação. 2. Divisão do trabalho: fica mais viável dividir o trabalho em múltiplos times, já que cada time pode estar trabalhando em uma parte específica. Cada serviço é uma ‘caixa-preta’, um sistema fechado, então se um time modificar o comportamento interno do serviço, não vai afetar de forma negativa os demais serviços. 3. Teste: pelo mesmo motivo, por serem sistemas fechados, uma arquitetura de serviços é mais fácil de testar do que uma arquitetura de monólito. 4. Complexidade controlada: a complexidade é controlada, ou, de certa forma, contida dentro de cada serviço. Imagine um serviço que seja responsável por fazer um cálculo matemático complexo: se esse código estiver dentro do monólito, para mexer no monólito com segurança, todos devem entender como esse cálculo é feito e como ele interage com o resto do código. Já, se ficar contido em um serviço, quem precisar usar só precisa conhecer a interface de entrada e saída. Mas essas arquiteturas também têm suas desvantagens: 1. Complexidade de infraestrutura: ao invés de publicar uma aplicação (monólito), será necessário publicar múltiplas aplicações. Cada serviço terá seu ciclo de vida específico e precisa ser publicado e mantido. É inviável manter um ambiente como esse sem apoio de ferramentas de conteinerização e sem uma melhoria no ambiente de devops para aumentar a automação, além de ferramentas de monitoramento. Isso exige conhecimento especializado e equipe dedicada. 2. Custo inicial maior: Também é normal perceber um custo inicial maior de infraestrutura, e mesmo no tempo de desenvolvimento. Este custo inicial maior vai retornar com o tempo, pela capacidade de escalar. Conclusão: devo migrar para microsserviços?
Como em todas as evoluções tecnológicas, não existe one size fits all, ou seja, não existe solução que seja aplicável para todos os casos. Então não saia correndo para migrar para uma arquitetura de microsserviços. Avalie primeiramente se a aplicação que você está mantendo ou criando precisa escalar. Ela tem previsão de crescer bastante em funcionalidades ou em número de usuários? Algumas aplicações são feitas para atender um cenário específico, e terão um número estável de usuários. Outras são feitas para um uso temporário, com obsolescência planejada. Agora, se você está trabalhando em um negócio que tem modelo de negócio exponencial, ou se planeja evoluir muito a aplicação para atender muitos “módulos” ou áreas que são complexos por si só, então sugerimos que você se preocupe sim em conhecer esse tipo de arquitetura, para não deixar que sua aplicação se torne um gargalo para a evolução do negócio. Se quiser saber mais sobre microsserviços e entender como podemos lhe ajudar, basta preencher o formulário abaixo.