Decisões arquiteturais para micro serviços: tradeoffs, granularidade e fronteiras

Explore os trade-offs inerentes à decisões arquiteturais cruciais na construção de sistemas baseados em microserviços, descubra a importância da granularidade adequada e aprenda a estabelecer fronteiras sólidas. Esta palestra procura oferecer insights para pessoas arquitetas e desenvolvedoras que desejam criar sistemas robustos e eficientes.

Palestra apresentada no TDC de Porto Alegre de 12/2023

Transcript

1. DECISÕES ARQUITETURAIS PARA MICROSERVIÇOS: TRADEOFFS, GRANULARIDADE E FRONTEIRAS JÉSSICA FÉLIX (@JESSILYNEH)
2. POÁ, SP POA - PORTO ALEGRE
3. 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
6. Conceito vindo do artigo “The Mindset for Architectural Decisions” O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Aspectos de uma decisão que podemos considerar para avaliar rapidamente a sua importância
7. O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco
8. O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco
9. O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco
10. O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco
11. O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco
12. O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco
13. Decision Record (DR) @jessilyneh 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)
14. 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
15. Trade-offs na divisão de sistemas em microsserviços @jessilyneh
16. Trade-offs na divisão de sistemas em microsserviços @jessilyneh 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
17. Trade-offs na divisão de sistemas em microsserviços @jessilyneh Distribuição: Latência de chamadas remotas, overhead de rede e custos operacionais Chamadas em processos(in-process) e chamadas remotas(remote calls)
18. SISTEMAS DISTRIBUIDOS E MICROSSERVIÇOS A arquitetura de microsserviços é um tipo de sistema distribuído, porém os dois conceitos não são intercambiáveis.
19. Trade-offs na divisão de sistemas em microsserviços @jessilyneh Consistência eventual: atualização assíncrona, uso técnicas de sincronização ou compensação para atingir estado consistente.
20. Trade-offs na divisão de sistemas em microsserviços @jessilyneh 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.
21. Trade-offs na divisão de sistemas em microsserviços @jessilyneh 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
22. Trade-offs na divisão de sistemas em microsserviços @jessilyneh 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
23. Escolhendo a granularidade adequada @jessilyneh 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/
24. @jessilyneh fronteiras determinam como a funcionalidade do sistema é dividida entre os serviços individuais
25. Estabelecendo fronteiras entre microserviços @jessilyneh Boundaries Context (contexto delimitado): conceito fundamental no DDD, que ajuda a dividir e organizar modelos de domínio extensos
26. Estabelecendo fronteiras entre microserviços @jessilyneh 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.
27. Estabelecendo fronteiras entre microserviços @jessilyneh 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
28. Estabelecendo fronteiras entre microserviços @jessilyneh 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
29. @jessilyneh Inicie com microsserviços maiores e ajuste seus limites com base no feedback da equipe e experiência prática.
30. Comunicação Síncrona vs Assíncrona @jessilyneh 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
31. Comunicação Síncrona @jessilyneh 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.
32. Comunicação Síncrona vs Assíncrona @jessilyneh 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
33. Comunicação Assíncrona @jessilyneh 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.
34. Uso Combinado @jessilyneh 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.
35. Impacto das métricas de Desempenho e Escalabilidade @jessilyneh 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.
36. Ações: métricas de Desempenho e Escalabilidade @jessilyneh 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
37. Como Avaliar e Refinar Decisões arquiteturais @jessilyneh 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
38. Referências @jessilyneh 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
39. Referências @jessilyneh 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/