Isto é o que ouvimos quando falamos com clientes. O primeiro desafio que normalmente ouvimos é relacionado a escala.
Na gráfico da esquerda conseguimos visualizar a escala da Amazon.com nos últimos anos e conseguimos observer grandes picos que são na verdade bem previsíveis.
No outro lado, temos informações sobre outros retailers. Note que Missguided é uma empresa que trabalha utilizando ferramentas como midias sociais. Desta maneira, não conseguindo ser tão previsível.
Escala não é o único desafio que varejistas encontram ao criar sistemas de e-commerce.
Deploty em novos países, escalabilidade, entender o que está ocorrento durante a operação.
Antigamente existiam algumas formas para solucionar este problema. No entanto estas formas não são necessariamente adequadas aos dias de hoje.
Esta é a arquitetura típica utilizada por plataformas de e-commerce, no entanto existem alguns problemas com esta arquitetura: pontos únicos de falha, problemas com database, upgrades, fatos que podem implementar downtimes.Então vamos partir do princípio que você gostaria de mover esta arquitetura para a AWS. Qual seria o primeiro passo?
O primeiro passo é mover o seu banco de dados. Uma vez que todos os dados estão efetivamente no seu banco de dados, precisamos garantir que ele seja escalável, a prova de falhas.
Quando você move para o RDS, você vai receber grandes benefícios logo de cara, como backups, gerencia do Sistema operacional, multi-az e a possibilidade de escale out implementando read replicas
E quanto a aplicação?
Ela precisa ser escalável. Temos a feature de auto-scaling que permite escalar a quantidade de servidores mas alguns sistemas legados não suportam esta facilidade.
Seu negócio pedindo mais mudanças.
Você por outro lado tentando “segurar” este ímpeto.
Trabalhando com períodos de freezing.
Por isso a sua nova arquitetura precisa ser escalável, permitir que você evolua de forma ágil.
Implementar muitas mudanças com um uptime ainda melhor.
A prova de future: você nunca sabe como será o future, portanto crie aplica;cões que permitam a evolução do seu noegócio.
Orientado a negócios: não inicie a partir do setor de TI. Comece entendendo o que o negócio precisa.
Cost effective: tem que ser correlacionado com suas atividades. Você não quer lidar com um contrato de 5 anos caso seu negócio não esteja sendo tão lucrative.
Desacoplado: Permia que todos os times consigam trabalhar individualmente sem que todo o seu e-commerce fique indisponível. Arquiteturas desacopladas são por padrão mais a prova de futuro e resilientes
Otimizado para operações: você vai querer a maior disponibildade possível. Implemente self healing, automação, para permitir a escala do ambiente.
Como você decide por onde começar?
O primeiro, e mais importante passo é entender qual problema você está tentando resolver e a partir daí aumentar a agilidade do negócio.
Todos os e-commerces precisam basicamente das mesmas features.
Foque seu design em capacidades específicas.
Então como decidir tecnicamente o que implementar?
Microserviços.
O primeiro passo é decidir entre algumas opções:
A primeira coisa é definir como seus serviços irão se comunicar.
Então, decidir como armazenar os dados
E então definiar onde a sua lógica de negócios será executada.
Um Sistema para varejo é baseado em eventos.
Um novo pedido. Um novo produto entregue. Um novo cliente cadastrado.
Falamos sobre poder computacional. Então devemos falar sobre baixo acoplamento.
Você quer serviços conversando entre sia utilizando mensagens ou APIs
Os princípios relacionados a storage:
Aberto e extensive: a prova de future. Você não quer estar amarrado a alguma tecnologia.Multi region: provavelmente você não tem essa necessidade hoje mas poderá ter em breve
Pronto para escala: você nunca sabe qual será o seu pico de acessos. É melhor se você tiver um Sistema que pode escalar
Temos basicamente tres tipos:
Amazon Aurora: banco de dados desenvolvido pela AWS. Funciona bem com schemas já existentes
Altamente integrado com o ecossistema AWS
Suporte replicas multi-region
DynamoDB NoSQl
Oferece baixa latencia, focado em objetos. Usando NoSQL voce também pode ganhar agilidade porque não precisa ficar preso ou gerenciar mudanças de schemas
Amazon S3
Implementar alta disponibilidade em todas as camadas;
Escalabilidade, se possível, em todas as camadas;
Estar pronto para responder as requisições de maneira performática;
Ter visibilidade de todo o seu ambiente;
Ter um ambiente seguro.
Serviços gerenciados já entregam Alta Disponibilidade por padrão
SQS, SNS, API Gateway, Cognito, Kinesis, Pinpoint, AWS WAF...
Para vocês que usam Lambda:
Lambda fora da VPC – altamente disponível por padrão
Lambda dentro da VPC - necessário configurar ao menos duas subnets em duas AZs diferentes
Cuidado com a escalabilidade e performance!
Use Auto Scaling para “normalizar” a infraestrutura
Procure sempre escalar horizontalmente:
ELB + Auto Scaling para a camada de aplicação
ELB escala automaticamente*
Auto Scaling utiliza métricas do CloudWatch para disparar uma ação, como adicionar ou remover instâncias do grupo
Escale agressivamente, mas remova instâncias de maneira conservadora
Ex: >= 60% Add 4; >=75% Add 6. <=25% > Remove 1
Caso precise forçar o Auto Scaling para escalar agora, altere o valor do Desired
Para vocês que terão aumento instântaneo de tráfego:
Não dependa do Auto Scaling para suportar o pico inicial de tráfego
CloudFront para cache de borda
Reduz latência com seu usuário final
Reduz o número de requisições na origem
Utilize o S3 como origem de conteúdo estático (jpgs, html, js...)
TTL por Behavior determina o tempo de expiração dos objetos
Utilize versionamento de arquivos para atualizar rapidamente o conteúdo
Ex: imagem_1.jpg para imagem_2.jpg ou imagem.jpg?ver=2
Invalidação de objetos também é suportado. Mas há um custo por invalidação
Crie um DNS Alias para sua origem com TTL baixo
Resolva CacheMiss antes do Black Friday
CacheHit precisa estar com um alto HitRate antes do evento
Use cache do CloudFront ao invés do cache do API Gateway
Monitoramento = Observabilidade + Ação Automática
Monitorar EC2 e serviços gerenciados da AWS:
CloudWatch
Nagios (mais EC2)
Monitorar a aplicação em si (profiling):
New Relic
DataDog (ótimo para containers também)
Dynatrace
Zabbix (menos detalhes que as outras acima, porém gratuito )
Prometheus (Kubernetes alguém?)
Para vocês que usam Serverless
AWS X-Ray
Espaço em disco no EBS de log
Se precisar, habilite também o VPC Flow Logs
Reomendado: use chat
Realize o Well Architected para cada serviço ou workload.