O documento discute a transição de sistemas monolíticos para microserviços utilizando a AWS, destacando os benefícios da escalabilidade, resiliência e facilidade de gerenciamento. Aborda a importância de padrões de arquitetura, monitoramento e comunicação entre microserviços para evitar acoplamentos fortes. Por fim, apresenta um guia para a refatoração gradual do sistema monolítico, enfatizando a necessidade de uma estrutura básica sólida e um gerenciamento de versão eficaz.

1. Sistemas Distribuídos Utilizando
Microserviços e AWS
Jonas Silveira – jonas@silveira.eti.br
AWS Campinas
08/07/2017

2. Agenda
• Cloud
• Sistema monolítico
• Microserviços
• Sistemas distribuídos
• Refatoração

3. O autor
Jonas Silveira
jonas@silveira.eti.br
https://www.linkedin.com/in/jonassilveira

5. Por que Nuvem?
Con. 1
Con. 2
Datacenter Datacenter 2

6. Abordagem Monolítica
Sistema
Banco de dados
Controle
Usuários
Contas a
Pagar
Contas a
Receber
Emissão e
Guarda da NFe
Cadastro
Produtos
Cadastro
Fornecedores
Relatórios
Envio de
e-mail

7. Abordagem Monolítica
Prós
• Performático
• Fácil gerenciar
Contras
• Preso a uma tecnologia
• Alta curva de
aprendizado
• Pouco reaproveitamento
• Muitos programadores
“batem cabeça”
• Falha em um
componente
compromete o todo
• Dificuldades em escalar
tudo: aplicação, equipe,
base de dados, etc.
• Difícil escalar.

8. Por que não fatiar o grande
sistema em sistemas
menores?

9. A internet é
um grande
sistema
distribuído

10. Definição
Microserviços são serviços pequenos,
autônomos, que trabalham juntos.

11. Abordagem Microserviços
Controle
Usuários
Contas a
Pagar
Contas a
Receber
Emissão e
Guarda da NFe
Cadastro
Produtos
Cadastro
Fornecedores
Relatórios
Envio de
e-mail

12. Tamanho
Tempo para ser reescrito: duas semanas.
(Jon Eaves / RealEstate.com.au – Australia)
Equipes grandes o
suficiente para serem
alimentadas por duas pizzas
grandes.

13. Pontos importantes
• Serviços autônomos que trabalham juntos.
• Princípio da responsabilidade única.
• Comunicação através de chamadas de rede, para
evitar forte acoplamento.
• Mudar um serviço e deployar sem mudar mais nada.
• KISS – keep it short and simple.
• DRY – Don’t repeat yourself não é um problema

14. Benefícios
• Agnóstico à tecnologia (heterogeneidade).
• Resiliência - Problema não falha em cascada –
isolamento.
• Escalabilidade – não precisa escalar tudo.
• Facilidade de deploy (monolito é tudo), risco reduzido.
• Gestão dos times.
• Reaproveitamento / Diferentes composições.
• Fácil substituição.
• Usar outros datacenteres.

15. Deve-se definir padrões
• Monitoramento.
• Tipo de interface (HTTP/REST).
• Padrões de arquitetura (response codes 4xx, 5xx).
• Segurança.

16. Exemplo de Arquitetura

17. Exemplo de Arquitetura
Amazon
EC2
Frontend
Classic Load
Balancer
Auto Scaling
Amazon
S3
Amazon API
Gateway*
Amazon
EC2
Auto Scaling
Lambda
function
Amazon
RDS
Backend
Amazon
DynamoDB
Amazon
CloudWatch
Amazon
SNS
Internal Load
Balancer
Amazon S3
bucket

18. API Gateway

19. API Gateway
• Facilita o gerenciamento do ciclo de vida das APIs.
• Pode ser usado com endpoint Lambda.
• Monitoramento via CloudWatch.
• Autorização AWS.
• Permite definir controles de threshold.
• Permite criar uma camada de cache integrada
(cache de até 1 hora).
• Permite realizar modificações nas requisições e
respostas.
Amazon API
Gateway*

20. Acoplamento
Sistema Monolítico
Controle
Usuários
Contas a
Pagar
Contas a
Receber
Emissão e
Guarda da NFe
Cadastro
Produtos
Cadastro
Fornecedores
Relatórios
Envio de
e-mail
Emissão e
Guarda da NFe
Envio de
e-mail
Contas a
Receber
Forma como os diferentes componentes do sistema interagem.

21. Acoplamento
• Quanto mais forte o acoplamento, pior.
• Se um componente falha, o processo quebra.
• Módulos do sistema (ou Microserviços) devem
conversar entre si através da troca de mensagens.
• Desacoplamento favorece autonomia e
escalabilidade.

22. Filas
• Formas seguras de informar outro componente de
que algo aconteceu e/ou precisa ser feito.
• Comunicação “assíncrona”.
• Cada fila pode ter um ou muitos “usuários”,
favorecendo o paralelismo da aplicação.
• Reduz falhas do tipo “curto-circuito”.
• Permite “cadenciar” a execução.

23. Filas – exemplo 1
1. Sistema emite a NFe
2. Sistema grava um item na fila de envio de e-mails
3. Sistema gera o contas a receber
Worker fica lendo a fila de envio de e-mails para
realizar os disparos sempre que algum item for
lançado lá.
Emissão e
Guarda da NFe
Envio de
e-mail
Contas a
Receber
Worker

24. SQS
• Pode ser FIFO ou randômica (best-effort).
• Garantia de entrega.
• Permite definir tempo de “invisibilidade” da
mensagem.
• Até 256 Kb de texto por mensagem.
• Mensagens podem ser enviadas e lidas
simultaneamente.
Amazon
SQS

25. Notificações
• Notificar um ou mais componentes de que algo
aconteceu.
• Comunicação “assíncrona”.
• Modelo publicação / assinatura.
• Pode ser usado para notificar dispositivos móveis.

26. Notificações - Exemplo
1. Sistema emite a NFe
2. Sistema emite a notificação “NFe emitida”
3. Assinantes da notificação são informados
Emissão e
Guarda da NFe
Envio de
e-mail
Contas a
Receber
Autor principal (Emissão da NFe) não precisa
saber quem são os assinantes da notificação.

27. SNS
• Tipos de assinatura: Push móvel (dispositivos
Apple, Google e Kindle Fire), HTTP/HTTPS, E-mail/E-
mail-JSON, SMS, SQS, funções do AWS Lambda.

28. Custos vs. Tipo de Instâncias
Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
Consumo
Reserved
On
Demand
Spot

29. Coesão
• Os módulos/componentes do sistema devem ser
coerentes com o seu propósito.
• Um módulo não deve realizar papéis que deveriam
ser exclusivos de outros módulos: ações, consultas,
etc.  deve-se solicitar o dado ou ação ao outro
módulo.
• Se aplica também à camada de persistência de
dados (banco de dados).

30. Coesão - Exemplo
• Listagem de fornecedores: quem o cadastrou?
Sistema Monolítico
Banco de dados Monolítico
Controle
Usuários
Contas a
Pagar
Contas a
Receber
Emissão e
Guarda da NFe
Cadastro
Produtos
Cadastro
Fornecedores
Relatórios
Envio de
e-mail

31. Segurança
• Uso o API Gateway para autenticar e os
microserviços para autorizar.
• Não exponha todos os microserviços na web.
• Use um API gateway interno e um externo.
• Use APIs de composição para acessar APIs internas.
• Controle o threshold das requisições.

32. Monitoramento
• Use o CloudWatch para monitorar as falhas.
• Importante monitorar o tempo de resposta.

33. Versionamento
• MAJOR.MINOR.PATCH
Major  Mudanças significativas que podem
quebrar a aplicação.
Minor  Mudanças que não quebram a aplicação,
normalmente são melhorias.
Patch  Correções.

34. Coexistência de Versões

35. IAM Role
IAM
Role facilita concessão
ae acessos aos recursos
AWS
Use sempre!

36. Do monolito para microserviços
1. Construa uma estrutura básica: Autenticação, API
Gateway, ferramentas de apoio (logs, etc.),
automação e padrões de API.
2. Unificar mecanismos de autenticação: faça o velho
usar o novo.
3. Identifique os componentes do sistema (aplicação e
banco de dados).
4. Crie os novos microserviços e faça os componentes
antigos do monolito usarem eles
5. Repita o item 4 até o monolito deixar de existir,
restando apenas a interface do usuário.
Strangler

37. Refatoração - Strangler

38. Orientação a custo
Data
Science
Transacional

39. Resumo
• Aplicações distribuídas facilitam escalabilidade e
são mais robustas, porém possui maior
complexidade.
• Arquitetura é fator chave de sucesso.
• Ferramentas na AWS:
• API Gateway
• Cloudwatch
• SNS
• SQS
• IAM
• EC2 / ELB

40. Dúvidas?