Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Decisões arquiteturais para micro serviços: tra...

Jessilyneh
December 05, 2023

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

Jessilyneh

December 05, 2023
Tweet

More Decks by Jessilyneh

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  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. 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)
  10. 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
  11. 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
  12. 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)
  13. 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.
  14. 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.
  15. 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.
  16. 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
  17. 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
  18. 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/
  19. 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
  20. 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.
  21. 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
  22. 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
  23. @jessilyneh Inicie com microsserviços maiores e ajuste seus limites com

    base no feedback da equipe e experiência prática.
  24. 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
  25. 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.
  26. 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
  27. 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.
  28. 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.
  29. 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.
  30. 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
  31. 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
  32. 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