Desafios e Lições Aprendidas na Migração de Monólitos para Microsserviços em Java

A migração de aplicações monolíticas para uma arquitetura de microsserviços representa um dos maiores desafios enfrentados por equipes de desenvolvimento modernas. Nesta palestra, exploraremos as complexidades dessa transição, focando especificamente em aplicações Java. Discutiremos as melhores práticas para a decomposição de monólitos, a gestão de dependências e a refatoração de dados, além de abordar as armadilhas comuns que as equipes encontram durante o processo.
Utilizando exemplos práticos e estudos de caso, analisaremos como a adoção de microsserviços pode melhorar a escalabilidade, a agilidade e a resiliência das aplicações. Também abordaremos a importância de uma estratégia de migração bem definida e as ferramentas que podem facilitar essa jornada.

1. DESAFIOS E LIÇÕES APRENDIDAS NA MIGRAÇÃO DE MONÓLITOS PARA MICROSERVIÇOS EM JAVA JÉSSICA FÉLIX (@JESSILYNEH)
2. Indicação de leitura sobre o assunto
3. Sistemas monolíticos podem ser vantajosos! Subir rapidamente uma PoC ou MVP para validar um negócio ou produto; O ambiente de desenvolvimento fica mais simples quando a arquitetura é monolítica; Mais simples de testar, pois é possível testar a aplicação de ponta a ponta em um único lugar; Baixa comunicação entre redes; Topologia de implantação mais simples. https://www.softplan.com.br/tech-writers/tecnicas-para-migrar-o-seu-sistema-monolitico-para-microsservicos/
4. Tipos de Sistemas Monolíticos Sistema Monolítico de Único Processo Todas as funcionalidades da aplicação são agrupadas em um único executável ou processo. Todo o código da aplicação reside em um único projeto, o que facilita a construção e a implantação. A comunicação entre os componentes é rápida, pois ocorre em memória. Desafios: À medida que a aplicação cresce, pode se tornar difícil de manter e escalar.
5. Tipos de Sistemas Monolíticos Monolítico Distribuído Variação em que a aplicação ainda é considerada monolítica em termos de estrutura de código, mas é implantada em múltiplos servidores ou contêineres. Pode ser distribuído em diferentes máquinas e a comunicação entre as partes do sistema pode ser feita através de chamadas de rede, o que pode introduzir latência. Distribuição pode aumentar a complexidade na gestão de estado e na comunicação entre os componentes, mesmo com lógica de negócios unificada.
6. Monolito versus Microsserviço Uma arquitetura monolítica é um modelo de software onde todos os componentes de uma aplicação estão interligados e são executados como uma única unidade. A arquitetura de microsserviços divide a aplicação em serviços independentes que se comunicam. Cada serviço é responsável por uma funcionalidade específica e pode ser desenvolvido, implantado e escalado de forma autônoma.
7. Definição de Microserviços James Lewis https://martinfowler.com/articles/microservices.html
8. Características de Arquiteturas de Microsserviços Serviços são componentes independentemente substituíveis e atualizáveis, em contraste com bibliotecas linkadas em um processo. Serviços são divididos com base em capacidades de negócios, com equipes cross-funcionais responsáveis por cada serviço. Equipes são responsáveis pelos serviços durante todo o ciclo de vida, em vez de projetos com prazos definidos. Aplicações são compostas por serviços com lógica interna, se comunicando através de protocolos leves como HTTP e mensageria.
9. Características de Arquiteturas de Microsserviços Cada serviço pode usar diferentes linguagens, ferramentas e padrões, com foco em fornecer ferramentas úteis para outros desenvolvedores. Cada serviço gerencia seu próprio banco de dados, com a integração entre serviços feita através de APIs. Plataformas de nuvem e containers facilitam a implantação automatizada de serviços. Serviços evoluem de forma independente, com foco em facilitar a evolução gradual da arquitetura.
10. Características de Arquiteturas de Microsserviços Cada microsserviço pode ser implantado de forma independente, permitindo que mudanças em um serviço não afetem diretamente os outros. Isso facilita atualizações e escalabilidade, pois as equipes podem trabalhar em diferentes serviços simultaneamente sem a necessidade de coordenar implantações de todo o sistema.
11. Monolito versus Microsserviço https://aws.amazon.com/pt/microservices/
12. Onde os requisitos de negócios não são claros ou estão em constante mudança, resultando em serviços que não atendem às necessidades do negócio ou que são excessivamente complexos. Sistemas de ERP instalados localmente, a dependência de ambientes específicos do cliente e a complexidade de customizações e integrações dificultam muito a migração para uma arquitetura de microsserviços. QUANDO NÃO MIGRAR? https://www.softplan.com.br/tech-writers/tecnicas-para-migrar-o-seu-sistema-monolitico-para-microsservicos/
13. Organizações que projetam sistemas são obrigadas a produzir projetos que são cópias das estruturas de comunicação dessas organizações E QUANDO MIGRAR? Melvin Conway,1968 https://www.melconway.com/Home/Committees_Paper.html
14. Quando migrar a sua arquitetura? @jessilyneh
15. PORÉM, ENTRETANTO, TODAVIA
16. MODERNIZAÇÃO DE LEGADO VALE A PENA? https://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy- platforms/
17. MODERNIZAÇÃO DE LEGADO VALE A PENA? https://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy- platforms/ As empresas tendem a adiar investimentos significativos até que a necessidade se torne urgente. Ciclos de lançamento mais longos e qualidade de entrega em declínio são um sinal de necessidade de modernização a dor de negócios e de TI deve ser quantificada para justificar a modernização
18. MODERNIZAÇÃO DE LEGADO VALE A PENA? https://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy- platforms/ A falta de comunicação pode levar a iniciativas que não estão alinhadas com as prioridades de negócios. A abordagem do "strangler application" é uma forma de substituir gradualmente um sistema legado, permitindo que novos componentes sejam integrados enquanto o sistema antigo é desativado.
19. A Lei de Conway… pode ser resumida como “Organizações disfuncionais tendem a criar aplicativos disfuncionais”. Parafraseando Einstein, você não pode consertar um problema de dentro da mesma mentalidade que o criou, então muitas vezes vale a pena investigar se a reestruturação de sua organização ou equipe impediria que o novo aplicativo exibisse todas as mesmas disfunções estruturais do original. No que poderia ser chamado de “manobra de Conway inversa”, você pode querer começar quebrando silos que restringem a capacidade da equipe de colaborar efetivamente. QUANDO MIGRAR? Jonny Leroy, 2010 https://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy- platforms/
20. A ARQUITETURA DE SOFTWARE COMPREENDE NÃO APENAS A ESTRUTURA CENTRAL DE UM SISTEMA, MAS TAMBÉM DECISÕES ESSENCIAIS DE DESIGN. Software Architecture Knowledge Management: Theory and Practice
23. Conceito vindo do artigo “The Mindset for Architectural Decisions” O Papel das Decisões Arquiteturais - PRILER checklist Aspectos de uma decisão que podemos considerar para avaliar rapidamente a sua importância @jessilyneh
24. O Papel das Decisões Arquiteturais - PRILER checklist Prioridade e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco @jessilyneh
25. Decision Record (DR) Iniciar, debater e arquivar uma escolha importante, com seu contexto e consequências. Um registro de decisão (DL) Uma decisão Um requisito significativo (SR) @jessilyneh
26. FOCO NA ANÁLISE DE CENÁRIO NÃO PREPARA PARA A EROSÃO DA ARQUITETURA, ENQUANTO O FOCAR APENAS NAS MÉTRICAS DE CÓDIGO NO NÍVEL DA ARQUITETURA SERIA NEGLIGENCIAR REQUISITOS E TECNOLOGIAS EM MUDANÇA. Measuring Architecture Sustainability - Heiko Koziolek, Dominik Domis, Thomas Goldschmidt, Philipp Vorst @jessilyneh
27. Desafios de migração Decomposição do Monolito: A decomposição inadequada pode resultar em serviços que são excessivamente acoplados, perdendo os benefícios da arquitetura de microsserviços Gerenciamento de dados: É ideal que cada microsserviço tenha seu próprio banco de dados para garantir a autonomia mas, isso pode complicar a migração de dados e a consistência entre serviços, especialmente se os dados precisarem ser compartilhados @jessilyneh
28. Trade-offs na divisão de sistemas em microsserviços @jessilyneh
29. Trade-offs na divisão de sistemas em microsserviços Limites de módulo: definir os limites de cada serviço pode ser um desafio, e acertá-los é crucial para o desempenho do sistema Conway's Law - as arquiteturas dos sistemas são semelhantes à organização da equipe de desenvolvimento que os construiu @jessilyneh
30. Trade-offs na divisão de sistemas em microsserviços Distribuição: Latência de chamadas remotas, overhead de rede e custos operacionais Chamadas em processos(in-process) e chamadas remotas(remote calls) @jessilyneh
31. Trade-offs na divisão de sistemas em microsserviços Consistência eventual: atualização assíncrona, uso técnicas de sincronização ou compensação para atingir estado consistente. Diversidade tecnológica: aplicações em tecnologias diversas, aumento de custo de manutenção. Segurança: Mais pontos de exploração para atacantes, gerenciamento de acessos, monitoramento e auditoria, atualizações constantes Orquestração: Interação coordenada para funcionalidades completas, transações distribuidas, gestão de configuração @jessilyneh
32. Escolhendo a granularidade adequada tamanho e complexidade de um sistema microsserviço deve: refletir uma unidade de negócios ou um domínio coeso ser capaz de evoluir independentemente dos outros ter fácil comunicação considerar requisitos de desempenho, como responsividade e processamento de dados https://architecturenotes.co/granularity-of-systems/ @jessilyneh
33. Escala de aplicações @jessilyneh https://www.thoughtworks.com/pt-br/insights/blog/microservices-nutshell
34. fronteiras determinam como a funcionalidade do sistema é dividida entre os serviços individuais @jessilyneh
35. Estabelecendo fronteiras entre microserviços Boundaries Context (contexto delimitado): conceito fundamental no DDD, que ajuda a dividir e organizar modelos de domínio extensos Responsabilidades: Uma parte limitada da lógica de negócios. Limite de transações: Cuidado com casos de falhas, considere estratégias como consistência eventual Requisitos de desempenho e escalabilidade Contratos explícitos entre as APIs @jessilyneh
36. Inicie com microsserviços maiores e ajuste seus limites com base no feedback da equipe e experiência prática. @jessilyneh
37. Comunicação Síncrona vs Assíncrona Síncrona: as chamadas criam uma cadeia de dependências por meio de todos os serviços Um serviço que faz uma chamada síncrona para um carrinho de compras também pode ficar dependente do pagamento associado e dos serviços de armazenamento. Se um ou mais desses serviços não estiverem disponíveis, é improvável que o chamador receba uma resposta. Mesmo que haja uma resposta, pode demorar tanto que o usuário encerrará a sessão @jessilyneh
38. Comunicação Síncrona Padrão de Requisição-Resposta Bloqueio de Recursos Simplicidade de Implementação Depuração Simples Latência de Rede Crítica: Em cenários onde a latência de rede é crítica, a comunicação síncrona pode ser preferível, pois a resposta é imediata. @jessilyneh
39. Comunicação Síncrona vs Assíncrona Assíncrona: Pode ser realizada por meio de mensagens assíncronas ou sondagem HTTP, aliada a uso de message brokers, como Kafka ou RabbitMQ. Cada microsserviço envia mensagens para o message broker e os outros microsserviços pegam as mensagens quando estiverem prontos @jessilyneh
40. Comunicação Assíncrona Desacoplamento e Escalabilidade Resiliência O emissor não fica bloqueado esperando por uma resposta. Redução de Sobrecarga .Filas de Mensagens Complexidade Adicional: Especialmente na lógica de tratamento de mensagens e na coordenação de eventos. @jessilyneh
41. Uso Combinado Operações críticas em tempo real podem ocorrer de forma síncrona, enquanto operações não críticas ou processamentos em lote podem ser tratados de forma assíncrona. @jessilyneh
42. Impacto das métricas de Desempenho e Escalabilidade Tempo de Resposta: baixos tempos de resposta são desejáveis para garantir uma resposta rápida às solicitações do cliente. Taxa de Erros: Podem afetar a confiabilidade do sistema e a satisfação do usuário. Utilização de Recursos (CPU, Memória): altas taxas de utilização podem indicar a necessidade de escalabilidade ou otimização de código. Latência de Rede: podem prejudicar o desempenho geral do sistema e exigir estratégias de otimização. @jessilyneh
43. Complexidades envolvidas na transição Nova infraestrutura: A migração para microsserviços geralmente requer a adoção de novas infraestruturas, como contêineres (Docker), orquestradores (Kubernetes) ou serviços cloud (AWS, Azure, Google) Testes: Testar microsserviços é mais desafiador do que testar um monolito, pois envolve verificar a interação entre vários serviços. Cultura Organizacional: A transição para microsserviços pode exigir uma mudança na cultura organizacional, promovendo uma abordagem DevOps e a colaboração entre equipes. @jessilyneh
44. Ações: métricas de Desempenho e Escalabilidade Otimização de Código Escalonamento Automático: Utilizar sistemas de escalabilidade automática para ajustar dinamicamente o número de instâncias de microsserviços com base nas métricas de desempenho. Ajuste de Recursos Estratégias de Cache: Implementar estratégias de cache para reduzir a carga em microsserviços e melhorar os tempos de resposta. Revisão de Arquitetura @jessilyneh
45. Como Avaliar e Refinar Decisões arquiteturais Identificar microsserviços Avaliar as decisões arquitetônicas Discutir com a equipe Avaliar e preparar microsserviços Avaliar e refazer as decisões arquitetônicas .Monitorar e ajustar @jessilyneh
46. Armadilhas mais comuns na migração Tentar reescrever todo o sistema de uma vez, Avaliar as decisões arquitetônicas. Permita que o sistema monolítico e os novos serviços coexistam durante a transição Subestimar a complexidade da arquitetura de microsserviços, levando a problemas de desempenho e integração.Avaliar e preparar microsserviços Negligenciar a governança de dados, causando inconsistências e problemas de integridade. @jessilyneh
47. Java para construir microsserviços @jessilyneh
48. Frameworks e bibliotecas Spring Boot É um dos frameworks mais populares para desenvolvimento de microsserviços em Java. Ele simplifica a configuração e o desenvolvimento de aplicações, facilitando criar serviços rapidamente com menos configuração.Também oferece suporte para integração com o Spring Cloud. @jessilyneh
49. Frameworks e bibliotecas Spring Cloud Permite que as configurações de todos os microsserviços sejam geridas em um único local, facilitando a manutenção. Ajuda os microsserviços a se encontrarem uns aos outros em um ambiente distribuído, utilizando servidores de descoberta como Eureka. Implementa padrões de resiliência, como o padrão Circuit Breaker, que ajuda a evitar falhas em cascata quando um serviço está indisponível. @jessilyneh
50. Gerenciamento de Dependências Maven: É um gerenciador de projetos que facilita a construção, o gerenciamento de dependências e a configuração de projetos Java. Permite declarar as bibliotecas de que seu projeto depende, e o Maven se encarrega de baixá-las e configurá-las. @jessilyneh
51. Maven Vantagens: Possui um sistema robusto de gerenciamento de dependências, que permite a fácil inclusão e atualização de bibliotecas. Impõe uma estrutura de projeto padrão, o que pode ajudar na organização e na consistência entre projetos. A comunidade de Maven é grande, com vasta documentação e suporte, facilitando a resolução de problemas. @jessilyneh https://cursos.alura.com.br/forum/topico-maven-vs-gradle-25930
52. Maven - Vantagens e Desvantagens Desvantagens Embora XML seja familiar, pode se tornar complicado em projetos grandes, resultando em arquivos de configuração extensos e difíceis de gerenciar. Maven é menos flexível em comparação com Gradle, especialmente em projetos complexos que exigem configurações dinâmicas. Maven não possui suporte tão eficiente para compilações incrementais, o que pode resultar em tempos de compilação mais longos. @jessilyneh
53. Maven - Melhores casos de uso Projetos Pequenos e Simples: Maven é ideal para projetos menores onde a simplicidade e a familiaridade são mais importantes do que a flexibilidade. Equipes com Experiência em Maven: Se a equipe já tem experiência com Maven, pode ser mais eficiente continuar usando essa ferramenta. Aplicações com Estruturas Padrão: Projetos que se beneficiam de uma estrutura de projeto padrão e onde a configuração não é excessivamente complexa. @jessilyneh
54. Gerenciamento de Dependências @jessilyneh Gradle: Sistema de automação de construção que combina a flexibilidade do Apache Ant com a conveniência do Maven. Gradle permite que você gerencie dependências de maneira mais dinâmica e é especialmente útil em projetos que exigem diferentes versões de bibliotecas.
55. Gradle - Vantagens e Desvantagens É projetado para compilações incrementais, o que significa que ele recompila apenas as partes do código que foram alteradas, reduzindo significativamente o tempo de compilação. Lida bem com projetos que contêm múltiplos módulos, permitindo uma configuração mais simples e organizada. É amplamente adotado em ambientes modernos, como desenvolvimento de aplicativos Android, e se integra bem com ferramentas de CI/CD. @jessilyneh
56. Gradle - Vantagens e Desvantagens Para desenvolvedores que não estão familiarizados com Groovy ou Kotlin, a curva de aprendizado pode ser mais acentuada. A flexibilidade de Gradle pode levar a uma configuração inicial mais complexa, especialmente em projetos simples onde Maven poderia ser suficiente. @jessilyneh
57. Gradle - Melhores casos de uso Projetos Grandes e Complexos: Gradle é mais adequado para projetos que exigem configurações dinâmicas e onde a flexibilidade é necessária. Desenvolvimento de Aplicativos Android: Gradle é a ferramenta padrão para projetos Android, oferecendo suporte robusto para esse tipo de desenvolvimento. Ambientes de CI/CD: Em cenários onde a automação e a integração contínua são essenciais, Gradle pode oferecer vantagens significativas com suas compilações incrementais e flexibilidade. @jessilyneh
58. Persistência de Dados Autonomia: Cada serviço pode gerenciar seus dados de forma independente, o que facilita a manutenção e a evolução do serviço sem impactar outros serviços. Escalabilidade: Serviços podem ser escalados de forma independente, permitindo aumento da capacidade de armazenamento e processamento apenas para os serviços que realmente precisam. Flexibilidade: Diferentes serviços podem usar diferentes tipos de bancos de dados (relacional, NoSQL, etc.), dependendo de suas necessidades específicas. @jessilyneh
59. @jessilyneh the scale cube Este cubo é descrito no livro de Martin Abbott e Michael Fisher, The Art of Scalability (Addison- Wesley, 2015).
60. Referências https://www.architectureandgovernance.com/applications-technology/the-mindset-for- architectural-decisions/ M.A. Babar et al., Software Architecture Knowledge Management: Theory and Practice, Springer, 2009. https://www.infoq.com/articles/sustainable-architectural-design-decisions/ https://adr.github.io/ https://www.koziolek.de/docs/Koziolek2013-IEEE-SW-preprint.pdf https://github.com/joelparkerhenderson/decision-record https://martinfowler.com/bliki/ConwaysLaw.html @jessilyneh
61. Referências https://martinfowler.com/articles/microservice-trade-offs.html https://martinfowler.com/articles/distributed-objects-microservices.html https://www.researchgate.net/publication/334305107_mvIMS_A_Finer- Scalable_Architecture_Based_on_Microservices https://architecturenotes.co/granularity-of-systems/ QuQuando é o momento de migrar do monólito para microservices? Elder Moraes: https://youtu.be/on1wVvLT1ec?si=b6jhnHdh2IGXZG1e https://www.melconway.com/Home/Committees_Paper.html https://intellyx.com/2015/06/22/devops-insights-into-conways-law/ @jessilyneh
62. Referências @jessilyneh https://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy-platforms/ https://www.thoughtworks.com/pt-br/insights/blog/microservices-nutshell https://www.softplan.com.br/tech-writers/tecnicas-para-migrar-o-seu-sistema- monolitico-para-microsservicos/ https://cursos.alura.com.br/forum/topico-maven-vs-gradle-25930