Arquitetura de sistemas: organizar monólitos e migrar para microserviços

Monólitos em Sistemas Modernos - Apresentacao

Apresentando o curso e seus objetivos

Olá, bem-vindo a mais um de nossos cursos sobre arquitetura. Este curso estará muito focado em estilos de arquitetura, principalmente em monólitos, monólitos modulares e microserviços. Vamos discutir um pouco sobre as diferenças entre esses estilos, algumas de suas características, o que cada um costuma resolver, quais são as complexidades que se acrescentam quando escolhemos um desses estilos e estratégias ao migrar de estilo ou tomar decisões em nível arquitetônico.

Introduzindo o instrutor e sua experiência

Meu nome é Murilo.

Audiodescrição: Murilo é um homem jovem de trinta e poucos anos, tem a pele clara, cabelo grisalho que começou a aparecer cedo, e possui uma barba um pouco cheia e bem delineada.

Atualmente, somos Lead Software Engineer, algo semelhante a Tech Lead, em uma empresa estadunidense chamada Income Payments, onde nosso produto principal são cartões pré-pagos e gift cards (cartões de presente). Temos dez anos de experiência na área, tendo passado por empresas como Mercado Livre, Itaú, Santander e algumas outras. Nosso foco sempre foi construir sistemas que crescem junto com o negócio, pois acreditamos que, embora as pessoas gostem de criar sistemas mais complexos utilizando novas ferramentas, é fundamental estarmos alinhados com o que realmente gera valor e se encaixa no contexto atual do negócio.

Convidando para interação e encerrando a introdução

Sintam-se à vontade para nos contatar no LinkedIn, estamos sempre disponíveis para conversar. Esperamos que gostem das aulas e que aprendam bastante. Ficamos muito felizes em estar aqui compartilhando isso com vocês. Muito obrigado.

Monólitos em Sistemas Modernos - O que e e o que nao e um monolito

Discutindo o conceito de monolito

Olá, nesta primeira aula, começaremos discutindo um tema que é bastante polêmico em nossa área de Arquitetura e Engenharia de Software, principalmente porque é frequentemente mal compreendido: a questão do monolito. Este é um estilo arquitetônico que utilizamos em nossos sistemas e aplicações. Ao longo dos últimos anos e décadas, o monolito tem sido associado a algo legado, pouco performante e complexo.

Vamos iniciar esta aula falando sobre o que realmente é esse estilo arquitetônico, o que ele representa, e tentaremos desmistificar a ideia de que não é uma decisão sustentável a longo prazo. Assim, começamos discutindo o que é e o que não é um monolito. Se pensarmos no significado, a origem do termo refere-se a uma grande pedra, um grande objeto. Esse termo foi introduzido em nossa área de Engenharia para representar uma aplicação que encapsula toda a lógica e as regras de negócio de nossa empresa ou sistema.

Comparando monolitos e microserviços

Com o surgimento dos microserviços nos últimos anos, e o conceito desse estilo arquitetônico diferente, criou-se a ideia de que o monolito deixa de ser sustentável a longo prazo. No entanto, isso não é uma verdade universal, e aqui discutiremos muitos desses pontos para tentar entender quais são as propriedades de um monolito e o que acontece a longo prazo para que ele seja considerado obsoleto ou legado, além de como podemos evitar que isso ocorra.

Por exemplo, nesta apresentação, começamos focando nos pontos principais. O que é um monolito? É um artefato, uma aplicação unificada. Desdobramos nossa aplicação, com toda a regra de negócio embutida, como em um e-commerce, onde falamos de notificações, pedidos, clientes, tudo em uma única aplicação.

Evolução do conceito de monolito com SPAs

Com a introdução das aplicações SPA (Single Page Applications - Aplicações de Página Única) para o front-end, esse conceito evoluiu um pouco. Antes, o monolito englobava tudo, incluindo a renderização das páginas junto com a lógica de negócio. Desdobrávamos um único artefato, e a pessoa acessava e já recebia as páginas dali. Agora, esse conceito evoluiu, e temos monolitos que executam as regras de negócio, mas focados no back-end. O front-end pode ser considerado uma aplicação SPA com outro framework, que não faz parte do conceito de monolito que discutimos atualmente.

Quando falamos de um monolito, referimo-nos ao back-end da aplicação, um bloco único, um único desdobramento. No entanto, como mencionado no início do curso, ele pode ser organizado, testado de forma concisa e com qualidade, além de ser escalável. Esse é um ponto que discutiremos ao longo de nossas aulas.

Monolito versus legado e a importância do contexto

Um monolito é diferente de um legado. A decisão arquitetônica, o estilo arquitetônico que escolhemos para nossa aplicação, não está diretamente ligado ao desempenho. Ser um monolito não está diretamente relacionado a isso. Essa percepção foi construída ao longo do tempo. Portanto, sistemas novos podem e devem começar monolíticos. Por quê? Porque ainda não temos muito contexto sobre como o sistema será estruturado.

Não faz sentido querer iniciar uma empresa, uma startup, ou um sistema com uma arquitetura distribuída, como em microsserviços, se não sabemos como dividir esses microsserviços. Ainda não temos o conhecimento do negócio para definir onde estará a fronteira que separa um microsserviço de outro. Portanto, começando com o monolito, veremos nas outras aulas que teremos liberdade para gerenciar isso de uma forma muito mais fácil e, a longo prazo, podemos evoluí-lo se assim desejarmos. Se quisermos mudar nosso estilo arquitetônico, podemos, mas no início temos essa abertura.

Exemplos de sucesso e desafios de manutenção

Veremos alguns casos de várias empresas multimilionárias que até hoje executam monolitos em poucas instâncias, com toda a lógica de negócio embutida nesse monolito, mas desacoplada com limites definidos, fronteiras, o que faz com que esse monolito realmente seja performante e tenha uma manutenção simples. As equipes de desenvolvimento podem trabalhar nessa base de forma desacoplada e sem interferir no trabalho umas das outras. Falaremos um pouco sobre isso também.

Reforçando, o código ruim existirá em qualquer estilo arquitetônico. E não apenas código ruim, mas uma arquitetura deficiente, considerando outras decisões, a estrutura do software, a própria arquitetura de software. O código, independentemente do estilo arquitetônico que estivermos utilizando, se não tivermos um processo bem definido, uma governança clara, padrões definidos, isso acabará gerando um sistema difícil de manter, com baixo desempenho, no qual ninguém quererá trabalhar, e esse sim, acabará se tornando um legado.

Estruturas de monolito e a importância da disciplina

Por exemplo, temos uma estrutura de monolito mais adequada para uma solução e uma estrutura mais caótica. Existe até um termo cunhado na comunidade, que é Big Ball of Mud (grande bola de lama), que realmente representa essa dificuldade para manter uma solução. Fazemos uma alteração e, de repente, algo se quebra em outro lugar, como se fosse um monte de lama que se desmorona. As coisas não se mantêm. Tentamos iniciar um novo padrão arquitetônico, mas depois vem outra equipe, mexe, ou não conseguimos mantê-lo porque o código já está muito desestruturado.

No monolito mais estruturado, podemos ver algumas separações mais claras do tipo de serviço. Se estivermos usando uma estrutura por camadas, controller, service, repository, ou se formos usar use cases (casos de uso), que seria de outra forma, podemos ver que, apesar de estar tudo ali, ainda se mantém uma estrutura que a pessoa desenvolvedora vai olhar, à primeira vista, e poderá entender o fluxo e talvez fazer as alterações necessárias. Diferente do outro lado, que representa realmente tudo se comunicando com tudo, provavelmente com algumas dependências circulares, algumas coisas que não farão sentido.

Concluindo com a importância das fronteiras e governança

Então, a frase de encerramento deste slide: o estilo não causa a desordem. É a falta de disciplina, a falta de governança, de padrões definidos desde o início do projeto e tudo isso. Temos até uma menção a Martin Fowler, Monolith First. Ele escreveu um artigo sobre isso, focando realmente nesse conceito de que é uma grande ideia começar um sistema, uma arquitetura com um monolito. Porque, como dissemos no início, não temos um conhecimento profundo do que deve ser separado ou não, de como esses domínios devem ser compostos ou não. Assim, tendo um monolito, facilita muito no início para criar mais conhecimento sobre o negócio e ter base ao criar essas fronteiras.

Aqui, fronteiras equivocadas custam mais do que não ter fronteiras. Pensar que sabemos realmente como funciona esse domínio e já começar com uma arquitetura mais distribuída, onde os domínios não estão realmente corretos, fará com que esses serviços, esses componentes que criamos, fiquem muito acoplados. Não poderemos fazer uma alteração em um sem fazer no outro. Isso complicará muito nossa vida no futuro.

Monólitos em Sistemas Modernos - Vantagens reais do monolito

Discutindo as vantagens da arquitetura monolítica

Nesta aula, vamos discutir as vantagens de utilizar uma arquitetura monolítica em um sistema. Esse tema não é amplamente abordado na comunidade, pois, ao aprender, muitos tendem a focar em microserviços. No entanto, há diversas vantagens em adotar um estilo arquitetônico monolítico, e é sobre isso que vamos falar agora.

Inicialmente, podemos destacar a simplicidade operacional. Quando temos um único artefato para implantar, isso reduz significativamente o overhead na parte de infraestrutura e DevOps, que seria necessário em um estilo mais distribuído. Com um artefato, realizamos o build, criamos um pipeline, fazemos o build e o implantamos. Talvez o front-end esteja separado, mas vamos nos concentrar no conceito de monolito para uma arquitetura onde o back-end encapsula as regras de negócio.

Explorando a simplicidade e monitoramento em monolitos

Outra vantagem é a menor superfície de monitoramento. Podemos imaginar que, mesmo com múltiplas instâncias do mesmo monolito, trata-se de uma única aplicação. Não enfrentamos os problemas que surgem em sistemas distribuídos, e vamos aprofundar isso no futuro. Aqui, temos uma aplicação em execução, que pode estar em múltiplas instâncias, com logs simples e stack trace dos erros e do fluxo dos métodos chamados, tornando tudo mais simples.

Como mencionado, tudo está no mesmo processo. Temos o repositório, o monolito em execução no sistema, a base de código com o código presente, e podemos carregar o projeto completo no IDE. Toda a lógica de negócio, endpoints e diferentes domínios estão ali. Muitas vezes, isso é visto como uma desvantagem, pois a complexidade parece estar toda misturada. No entanto, com governança e estrutura, é possível organizar de forma eficiente, permitindo que todo o contexto esteja disponível para trabalhar, o que é muito mais simples do que fazer alterações em serviços separados e entender o que está acontecendo.

Facilitando o debug e testes em monolitos

O debug de ponta a ponta é outra vantagem. Quando uma solicitação entra, todo o fluxo de negócio ocorre internamente, incluindo a conexão com bancos de dados, e podemos ver tudo junto. A pessoa desenvolvedora, por exemplo, pode executar o debug localmente e visualizar o que está acontecendo de ponta a ponta. Os testes de integração também podem ser executados localmente, sem a necessidade de se preocupar com serviços externos para realizar esses testes e processos.

Além disso, o compilador é um aliado nas mudanças e refatorações. Com tudo em uma única base, é mais fácil garantir que não estamos quebrando contratos de comunicação entre partes. Se os serviços estivessem separados e desacoplados, seria mais difícil garantir que uma alteração não afetaria outra parte. Com tudo dentro da mesma estrutura, em tempo de compilação, já podemos identificar o que pode ser afetado, como um módulo ou domínio que estava usando um campo que foi removido. Isso é muito interessante e vantajoso.

Integrando IA e monolitos

Aqui, discutindo um pouco sobre IA no contexto de monolitos e a integração de todo o contexto, isso chamou nossa atenção. Inicialmente, pensávamos que era uma grande vantagem, considerando que as IDEs atuais já são AI First (focadas em IA) e AI Native (nativas em IA), oferecendo várias ferramentas para interagir com o código, alimentar o contexto de uma LLM (Modelo de Linguagem Grande) e outras funcionalidades. Com um monolito, ao carregar e executar a aplicação, a IDE se integra e obtém todo o contexto da aplicação e o que está ocorrendo.

No entanto, atualmente, falar de IA e programação com IA é algo muito novo e em rápido desenvolvimento. Surgem novas ferramentas, enquanto outras são rapidamente deprecadas. Portanto, não podemos afirmar que isso seja uma vantagem definitiva; é algo a ser considerado ao tomar decisões arquitetônicas. Por exemplo, ao carregar uma aplicação em uma IDE, já temos todo o contexto, mas qual é o impacto disso no consumo de tokens da IA? Ter tudo em um único lugar ou, por outro lado, ter mais componentes e serviços menores pode oferecer um contexto mais granular e específico de um domínio. Devemos sempre ter isso em mente ao tomar decisões, pois a IA pode impactar dependendo do sistema, da empresa, das ferramentas utilizadas, como LLM, autocompletado, revisão de PR, entre outras. Isso pode afetar a decisão arquitetônica entre monolitos, sistemas distribuídos ou outras opções.

Abordando transações ACID e latência em monolitos

Voltando à questão do monolito, temos a vantagem das transações ACID de forma gratuita. Quando falamos de banco de dados e transações, a atomicidade que essas transações proporcionam em um monolito é uma grande vantagem. Em sistemas distribuídos, isso se torna um dos principais desafios. Discutiremos os trade-offs de usar um sistema distribuído ou não, e as vantagens e desvantagens. A consistência de dados é uma grande desvantagem ao sair do monolito, pois não há uma forma simples e eficiente de garantir isso. Em microserviços, existem estratégias para garantir consistência, ou consistência eventual, mas não são tão assertivas e eficientes quanto uma transação direta em nível de banco de dados, algo que o monolito oferece ao integrar todo o contexto e fluxo em um único sistema.

Não precisamos nos aprofundar muito, mas ao falar de latência em um monolito, estamos lidando com chamadas de método a nível de processo, algo muito rápido, em nanosegundos. Em uma arquitetura distribuída, há um overhead de saltos de rede para comunicação, independentemente do protocolo escolhido, seja HTTP, gRPC, SOAP, etc. Isso resulta em um overhead direto ao sair de uma arquitetura monolítica. A diferença de latência é de ordens de magnitude, de nano para microsegundos, o que pode impactar o desempenho do negócio, dependendo do contexto e domínio do sistema.

Além disso, ao enviar uma solicitação HTTP, é necessário serializar e desserializar a resposta, seja em JSON, XML, etc. Isso também gera um overhead ao transformar o objeto interno do seu idioma de programação em algo que será transmitido pela rede, resultando em um overhead significativo.

Sobre o curso Arquitetura de sistemas: organizar monólitos e migrar para microserviços

O curso Arquitetura de sistemas: organizar monólitos e migrar para microserviços possui 208 minutos de vídeos, em um total de 39 atividades. Gostou? Conheça nossos outros cursos de Arquitetura em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Monólitos em Sistemas Modernos
• Arquitetura de Monólito Modular
• Arquitetura de Microserviços
• Integração entre Serviços
• Evolução de Arquitetura