Slide 1

Slide 1 text

DECISÕES ARQUITETURAIS PARA MICROSERVIÇOS: TRADEOFFS, GRANULARIDADE E FRONTEIRAS JÉSSICA FÉLIX (@JESSILYNEH)

Slide 2

Slide 2 text

POÁ, SP POA - PORTO ALEGRE

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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)

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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)

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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/

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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.

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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.

Slide 34

Slide 34 text

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.

Slide 35

Slide 35 text

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.

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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/