Conteúdo apresentado no Meetup do grupo AWS Campinas, em 08/07/2017. Foi feita uma apresentação sobre os conceitos de microserviços, como a AWS pode ajudar e no final uma técnica de como refatorar um sistema monolítico para microserviços.
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?
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.
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.
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
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
Por que a nuvem facilitou as coisas e viabilizou muitas outras pela redução da complexidade.
Custos
Complexidade
Coisas Prontas
Diferenças Azure / Google Cloud / AWS
Problemas para os vendors de hardware
Facilidade de gerenciamento/orquestração e capacidade computacional favorecem estruturas mais complexas
O que nos impede de transformar um sistema em vários?
Usar várias tecnologias?
Sistema monolítico: um grande problema
Coisas entrelaçadas tornam curva de aprendizado dura, pouco reaproveitamento
Preso a uma tecnologia
Muitos programadores “batem cabeça”
Falha em um componente compromete o todo
Dificuldades em escalar tudo: aplicação, equipe, base
A internet é um grande sistema distribuído
O que nos impede de transformar um sistema em vários?
Usar várias tecnologias?
Arquitetura abre um mundo de possibilidades
Monitoramento pode ser direcionado à pessoa certa
Front pode ser uma aplicação mobile, portal, outro sistema, etc.
Colocar API em outro local físico
Adquirir um sistema externo
Assíncrono vs. Síncrono
Falhas “curto circuito”
Garantia de execução ou não
Troca de mensagens / exemplos de quebra
Como usar filas (SQS):
Envia mensagem pra fila
Alguém consome
Auto-scale para trabalhar essa fila / instâncias SPOT
Monitoramento das filas usando CloudWatch
Dead letter queue
Outro uso: não deixar o usuário esperando
Notificações:
Assinantes: filas, lambda
Coerência com o propósito
Eric Evans’s DDD
Coesão do Banco de dados
Gateway Interno
Serviços a expor
Controle de threshold
Autorização microserviço / Autenticação gateway
SSO gateway
Cuidado com o que fixa exposto
RLK
Quem são seus usuários?
Não quebre a aplicação
Versionamento semântico: MAJOR.MINOR.PATCH
Uma CI por microserviço
Strangler – rotear chamdas par nova estrutura ; Big Bang
1) Estrutura “core”
Automatizar tudo o que der (orquestração) / definições de padrões da API / segurança / monitoramento
2) Unificar mecanismo de autenticação
3) Identificar os componentes do sistema (aplicação e banco)
4) Criar seu primeiro microserviço: legado passa a utilizá-lo
5) Começe a esvaziar o monolito