DESAFIOS E LIÇÕES APRENDIDAS NA MIGRAÇÃO DE MONÓLITOS PARA MICROSERVIÇOS EM JAVA JÉSSICA FÉLIX (@JESSILYNEH)

Indicação de leitura sobre o assunto

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/

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.

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.

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.

Definição de Microserviços James Lewis https://martinfowler.com/articles/microservices.html

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.

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.

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.

Monolito versus Microsserviço https://aws.amazon.com/pt/microservices/

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/

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

Quando migrar a sua arquitetura? @jessilyneh

PORÉM, ENTRETANTO, TODAVIA

MODERNIZAÇÃO DE LEGADO VALE A PENA? https://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy- platforms/

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

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.

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/

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

No content

No content

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

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

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

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

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

Trade-offs na divisão de sistemas em microsserviços @jessilyneh

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

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

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

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

Escala de aplicações @jessilyneh https://www.thoughtworks.com/pt-br/insights/blog/microservices-nutshell

fronteiras determinam como a funcionalidade do sistema é dividida entre os serviços individuais @jessilyneh

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

Inicie com microsserviços maiores e ajuste seus limites com base no feedback da equipe e experiência prática. @jessilyneh

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

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

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

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

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

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

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

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

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

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

Java para construir microsserviços @jessilyneh

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

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

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

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

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

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

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.

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

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

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

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

@jessilyneh the scale cube Este cubo é descrito no livro de Martin Abbott e Michael Fisher, The Art of Scalability (Addison- Wesley, 2015).

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

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

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