Uma pergunta que deve ser considerada ao desenvolver o seu projeto: faço como monólito, ou microsserviço? Mas afinal, o que é uma aplicação monólito e o que é uma aplicação microsserviço? No texto de hoje, vamos explorar um pouco mais sobre arquitetura de software e introduzir o conceito de monólitos e microsserviços para o seu projeto.
O que é uma aplicação monólito?
Chamamos de “monólito” uma aplicação feita em um único serviço. Isso quer dizer que todas as funcionalidades e recursos deste projeto foram feitos em um único lugar, um único projeto, um único código.
Para exemplificar uma aplicação monólito, vamos pensar em um ecommerce bem completo: um sistema com produtos cadastrados, disponíveis para a venda, com recursos de pagamento, acompanhamento de entrega, controle de estoque, disponibilização de relatórios para conferência financeira da loja, geração de notas fiscais, etc.
Em um modelo monólito, temos essa aplicação desenvolvida em um único projeto. No mesmo lugar que gerencia os produtos e está cadastro produtos no banco de dados existe também o gerenciador de estoque, o sistema de notas fiscais, os relatórios financeiros e o restante de funcionalidades.
Este é até o padrão mais utilizado entre os projetos, principalmente em projetos “simples e pequenos”, e se você está iniciando em desenvolvimento, deve até estar estranhando: “e tem outro jeito de fazer?”. Outro jeito, seria dividir este projeto em “miniprojetos”, chamados de microsserviços.
O que é uma aplicação em microsserviços?
Uma aplicação em microsserviços é quando conseguimos quebrar toda uma aplicação, em diversas outras aplicações menores.
Ainda seguindo o nosso exemplo de ecommerce, ao invés de termos todos os recursos em um só lugar, dividimos cada recurso em um “novo projeto”, delimitando bem o seu código conforme a funcionalidade daquele serviço e para onde ele deve ser responsabilizado.
Por fim, teremos um projeto, ou serviço, para gerenciar os produtos, outro para gerenciar o estoque, outro para gerar relatórios financeiros e outro para fazer o acompanhamento de entregas, sempre seguindo esta lógica de dividir os recursos de sua aplicação em outros projetos.
Neste modelo, importante dizer que estes microsserviços estão sempre conversando entre si, afinal, por mais que esteja dividido em vários pedaços, ainda temos uma única aplicação com um único objetivo: ser um ecommerce.
Essa arquitetura tem se tornado bastante comum em projetos maiores e mais complexos, sendo praticamente essencial para garantir o bom funcionamento da sua aplicação. Mas ainda pode parecer um pouco estranho: por que deixar minha aplicação mais complexa e com mais projetos a serem gerenciados?
Vantagens de uma arquitetura em microsserviços
Vamos continuar no exemplo de ecommerce para discutir vantagens e desvantagens de uma arquitetura em microsserviços. Nesse exemplo, temos um projeto bastante grande e complexo, com diversos recursos diferentes. Apenas com essa definição já é um ótimo pedido o uso da arquitetura de microsserviços, mas vamos entender por quê.
Vamos pensar na performance: nesse exemplo, temos diversos recursos que possuem usos bastante diferentes: os produtos, usado pelo cliente que acessa o ecommerce e quer comprar, e os relatórios financeiros, usados somente pela equipe financeira, interna a empresa. Em uma aplicação monólito, se tivermos muitos acessos no ecommerce, apenas para ver os produtos, perceberemos uma lentidão no sistema inteiro, inclusive nos relatórios financeiros. Já em uma aplicação em microsserviços, essa lentidão seria sentida somente na área de produtos, e manteríamos os outros serviços bastante estáveis.
Pensando também em custo, vamos pensar na escalabilidade da aplicação —ter um servidor melhor, ou aumentar o número de servidores disponíveis. É bem mais barato escalar um serviço pequeno, do que um serviço maior. No problema citado, em uma aplicação, monólito, teríamos que escalar todo o sistema, independente se é somente uma pequena parte dele que exige uma performance melhor. Já com uma aplicação em microsserviços, escalamos somente a serviço de produtos, e poderíamos deixar o serviço de relatórios pequeno. Microsserviços permitem que maior controle sobre a escalabilidade, equilibrando os gastos de infraestrutura.
Trazendo também para o gerenciamento do projeto, pense sempre que quanto maior o seu código, mais complexo ele fica. Aplicações grandes feitas em monólito costumam ter códigos enormes, o que realmente dificulta a manutenção. Aplicações em microsserviços tem como premissa serviços pequenos, com código simples e bastante objetivos, facilitando a manutenção e até mesmo abrindo espaço para múltiplas equipes trabalharem na aplicação.
Mas realmente, uma aplicação em microsserviço tem um custo alto: temos que gerenciar diversos pequenos projetos, temos que garantir que a comunicação entre os serviços seja sempre constante, e sim, a implementação no código é mais complexa e o gerenciamento da infraestrutura é também mais trabalhoso.
É uma questão de equilíbrio
Uma aplicação monólito pode ser exatamente o que você precisa —afinal, ela também tem suas vantagens: fácil implementação, menor gerenciamento de infraestrutura, e apenas um único projeto para “tomar conta”. Nem sempre uma arquitetura em microsserviços será importante para o seu projeto, e há situações que podem trazer mais custo do que benefícios.
Por exemplo, o blog da devGo. Não há necessidade nenhuma deste blog ser em microsserviços, seria até mesmo um exagero, o famoso “matar uma barata com um canhão”. Por aqui, precisamos nos concentrar somente em disponibilizar postagens aos leitores, não há necessidade de um melhor controle de escalabilidade, ou uma performance diferenciada para determinado recurso. Sendo sincero, não há nem mesmo outro recurso, é apenas um blog: criar postagens, e exibir postagens.
Como tudo em desenvolvimento de software, não existe uma regra. Você deve sempre pensar no seu projeto, o que ele pretende e o que você está disposto a fazer.
Nos próximos textos da devGo, vamos aprofundar em microsserviços e aprender como realmente implementar um projeto em microsserviços ou até mesmo fazer uma migração de monólito para microsserviços. Participe do nosso canal no Discord e se inscreva em nossa newsletter para acompanhar a devGo!