Padrões de arquitetura de aplicações na AWS

Implantando Aplicações na AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Conheça seu instrutor

Instrutor do curso Dunieski Otano, AWS Solutions Architect, com cerca de dez anos de experiência em nuvem

Por que a arquitetura certa importa

Diagrama (tema claro) em que uma escolha de arquitetura se ramifica em três fatores: acoplamento, estado e comunicação, acima de um pequeno ícone de balança para trade-offs

Arquitetura é um conjunto de trade-offs, não uma resposta única
- Três perguntas orientam cada escolha:
  - Quão fortemente os componentes estão acoplados?
  - Onde o estado fica?
  - A comunicação é síncrona ou assíncrona?
- Combine o padrão ao workload, não à moda

A cascata da noite de sexta

Uma API de pagamento lenta congela todo o checkout
Todos os serviços esperavam por ela de forma síncrona
A solução é arquitetura, não uma API mais rápida

Comparação lado a lado de serviços fortemente acoplados que travam versus serviços desacoplados por uma fila de mensagens

Como escolhas de arquitetura decidem o deploy

Diagrama comparando uma arquitetura frágil e fortemente acoplada, onde a falha de um serviço se espalha, versus um design resiliente em que uma fila isola a falha e os demais continuam atendendo

O padrão escolhido define como o app escala e falha
- Um design fortemente acoplado quebra sob carga
O padrão certo torna o deploy previsível
- Mesmo código, comportamentos muito diferentes em produção

Padrões de arquitetura essenciais

Monolítica: uma unidade de deploy, simples para começar
Microsserviços: serviços independentes, deploy separados
Orientada a eventos: componentes reagem a eventos, não a chamadas diretas
- Fanout é um subpadrão orientado a eventos: um evento chega a muitos consumidores

Três padrões de arquitetura lado a lado: monolítica como um bloco único empilhado, microsserviços como serviços independentes implantáveis e orientada a eventos com um barramento de eventos; fanout mostrado como subpadrão publicando um evento para muitos consumidores

Stateful vs stateless

Stateless: nenhum dado do cliente entre requisições
- Qualquer instância atende qualquer requisição
Stateful: a instância lembra interações anteriores
Stateless é o que permite escalar horizontalmente
- Leve o estado compartilhado para DynamoDB ou ElastiCache

Instância stateless que qualquer requisição pode alcançar à esquerda versus instância stateful vinculada a uma sessão de cliente à direita

Acoplamento forte vs frouxo

Acoplamento forte com chamador bloqueado aguardando um callee lento versus acoplamento frouxo com uma fila SQS amortecendo mensagens para o produtor continuar

Acoplamento forte: o chamador espera a resposta do callee
Um serviço lento trava toda a cadeia
Acoplamento frouxo: uma fila Amazon SQS fica entre serviços
O produtor continua mesmo se o consumidor cair

Síncrono vs assíncrono

Síncrona: o chamador bloqueia e espera o resultado
Use quando precisa da resposta agora
Assíncrona: o chamador delega o trabalho e retorna
Use para tarefas lentas, em rajadas ou não urgentes

Chamada síncrona com chamador bloqueado até a resposta chegar à esquerda versus entrega assíncrona que retorna imediatamente com processamento em segundo plano à direita

Padrões de resiliência para chamadas de terceiros

Retry com backoff exponencial: espere mais entre tentativas
Circuit breaker: pare de chamar um serviço com falha por um tempo
Dead-letter queue: estacione mensagens que continuam falhando
Combine-os; retries indiscriminados pioram panes

Três padrões de resiliência: curva de retry com backoff exponencial, circuit breaker interrompendo chamadas a um serviço com falha e dead-letter queue capturando mensagens que esgotam retries

Vamos praticar!

Implantando Aplicações na AWS