Este documento discute as vantagens e desvantagens de uma arquitetura de microserviços. As principais vantagens incluem a capacidade de implantar serviços independentemente, permitindo entregas contínuas mais rápidas. As principais desvantagens incluem a complexidade operacional adicional e a consistência eventual de dados entre serviços. O documento fornece dicas para lidar com desafios como integração, diversidade tecnológica e segurança.

1. Fábio Rosato
fabio.rosato@sensedia.com
@frosato
Vantagens e desvantagens de uma
arquitetura microservices

2. Fábio Rosato
Professional Services Manager
fabio.rosato@sensedia.com
@frosato

3.  SOA, Microservices e APIs
 Projetos bacanas e desafiadores
 Plataformas sensacionais
 Headquarter em Campinas,
escritórios em SP, Rio e EUA

4. Alguns Clientes

5. Agenda
Cenário
Estratégia de evolução
Dicas
Vantagens e desvantagens

6. Cenário

7. Microservices está
no Hype

8. Hype

9. Hype?

10. Cloud
Domain-
driven design
Service-
oriented
architecture
Continuous
delivery
Elementos chaves
para a ascensão dos
microservices…

11. Fazendo as
comparações...

12. WEB
UI
EMAIL
Adapter
URA
Adapter
Pagamentos
Adapter
Clientes
Pacotes
Reservas
Avaliações
Recomendações
PagamentosNotificações
DB
Adapter
REST
API
Monolítica
Arquitetura
http://alistair.cockburn.us/Hexagonal+architecture
Plataforma de
Viagem

13. Clientes
Pacotes
Reservas
Avaliações
Recomendações
Pagamentos
Notificações
Microservices
Arquitetura
Pagamentos
Adapter
URA
Adapter
EMAIL
Adapter
API
Gateway
REST
API
REST
API
REST
API
REST
API
REST
API
REST/AMPQ
API
REST/AMQP
API
WEB
UI
Plataforma de
Viagem

14. Application #1 Application #2
Application #3 Application #n
Cenário
Real

15. Cenário
Real
Application #1 Application #2
Application #3 Application #n
Aplicações moníliticas nem
sempre modularizadas
Comunicação interna e
externa caso-a-caso sem
padrão definido
Ciclos de entrega longos
(meses)
Dificuldade para evoluir e
implantar novas
tecnologias
Obsolecência tecnológica
Grandes bases
compartilhadas
√
√
√
√
√
√

16. Evolução

17. Manter e evoluir!

18. http://www.martinfowler.com/bliki/StranglerApplication.html
Strangler
Application
Application #1 Strangler Application
1

19. http://www.martinfowler.com/bliki/StranglerApplication.html
Application #1 Strangler Application
Strangler
Application1

20. Strangle Application
Domínios e
sub-domínios2
 Conceitos de negócio
 Bounded Context
 Domain Driven Design
Contexto A Contexto B

21. Strangle Application
Microservices
3
Microservice #n
Database
HTTP/REST

22. Governança
4  Definições de padrões
mínimos principalmente
na fronteira externa da
aplicação (contexto de
conexão)
 Informações para tomadas
de decisões em tempo de
design e runtime
 Importante na medida
certa!

23. Cultura
Devops5

24. Cultura
Devops5
 Times de desenvolvimento e operação atuando juntos
 Time de desenvolvimento criando scripts de automação
 Ciclos de entregas mais curtos (diários)

25. Dicas

26. Alguns Fatores
• Microservices não são necessariamente mais
fáceis de escalar
• Você pode aplicar mecanismos distintos de
segurança para os microservices

27. Integração
• Acertar a integração é o aspecto mais importante
da tecnologia associada a microservices.
• Prefira integrações direitas para aumentar a
autonomia
• Evitar de fazer alterações que mudem o contrato

28. Integração
• Mantenha sua tecnologia de APIs agnóstica (REST
HTTP / AMQP)
• Faça seus serviços simples para os consumidores
– De nada adianta ter um microservice bacana se ele é
difícil de ser utilizado
• Esconda os detalhes de implementação internos

29. Composição - Coreografia
Microservice #1 Microservice #2 Microservice #n
Banco Relacional Documentos Key/Store Data Base
API API API
Microservice #c
Camada de
coreografia
Camada de
dados

30. DRY – don’t repeat yourself
Código repetitivo você pode colocar em
um componente (library), mas
cuidado! Evoluções nos componentes
impactam todos os microservices que
dependem deles.

31. Client Library ou SDKs
• Criar um client library facilita o consumo do
microservices e mitiga o uso indevido
• O problema é a diversidade tecnológica e a
manutenção dos Client Library
• Cuidado: não deixe vazar lógicas que deveriam estar no
servidor para dentro do client da API. (Acoplamento)

32. Uso de múltiplas versões de serviços
concorrentes
• Manter instâncias de serviços novos e velhos e
rotear para um ou outro
– Utilize nas situações que alterar os consumidores
mais velhos tem um custo muito alto
– Ou em situações de um curto período de tempo
com implantações blue/greenn
• Coexistir diferentes endpoint

33. Architectural Safety
• Proteja-se dos serviços laranjas podres:
aqueles que estragam todos os outros
• Os butterflies são potencialmente mais
danosos. Monitore!
Microservice #1 Microservice #2 Microservice #3REST
API
REST
API
REST
API
Microservice #4
REST
API butterfly

34. Vantagens e
desvantagens
benefícios e consequências

35. Módulos com Fronteiras Fortes

36. Fortes Fronteiras de módulos
• Microservices
– A dissociação modular de
microservices funcionam
melhor porque os limites dos
módulos são uma barreira para
referências entre os módulos
– Você até pode ter um grande
acoplamento com
microservices, mas o esforço
certamente será maior
– O desafio é definir o domínios e
sub-domínios
– Funciona bem para equipes
isoladas (esquadrões)
• Monolítica
– É perfeitamente possível ter
limites firmes de módulos em
sistemas monolíticos, mas
requer disciplina e
acompanhamento
– É mais fácil bular as fronteiras,
e esse atalho feito amplamente
minam a estrutura modular do
sistema e o tornam um “lixo”

37. Distribuição

38. Distribuição
• Grande desvantagem:
– Ser muito distribuído
– Desempenho
• Latência de rede
• Custo de serialização e
deserialização
• Falácias da computação
distribuída*
• Dicas (Mitigações):
– Aumentar a granularidade
das chamadas
– Usar chamadas assíncronas
• melhoria de desempenho
• Porém é:
– Difícil de acertar
– Difícil de depurar
– Confiabilidade
• Programa-se para o fracasso e
suas consequências
* Falácias da computação distribuída: http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

39. Implantação Independente

40. Implantação Independente
• Simplicidade
– A unidade microservice é
mais simples, em tese é mais
fácil de implantar
– Problemas no microservice,
se ele for bem desenhado,
tendem a propagar menos
impacto no ambiente todo
• Scripts de automatização
– Quase um pré-requisito: é
difícil ser ágil fazendo
implantações manuais
• Entrega contínua
– Redução do tempo de ciclo
entre uma ideia e o software
em execução
– Respostas mais rápida as
mudanças do mercado
– Vantagem competitiva
• Feedbacks mais rápidos
– E ciclo de correções mais
rápidos

41. Consistência Eventual
#sqn

42. Consistência Eventual
• Causa: descentralização de
dados da abordagem
• É um efeito colateral para
garantir a disponibilidade
– Tradeoff entre
disponibilidade e consistência
dos dados
• Cache é importante!
– Invalidação de cache é difícil
– Dica: Utilize eventos para
invalidar cache
• Tolerância a inconsistência
(teorema de CAP)
– Consistency
– Availability
– Tolerance to network
partitions
http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

43. Diversidade Tecnológica

44. Diversidade Tecnológica
• Liberdade
– Fortalece a as escolhas
independentes de tecnologia
– Algumas linguagens e tipos de
armazenamento de dados são
mais adequados para
determinados tipos de
problemas
– O objetivo é resolver o
problema através das escolhas
mais inteligentes
– Experimentações de novas
tecnologias
• Padronização
– As questões de interface
(HTTP/REST, AMQP),
ferramentas de ambiente e
monitoração
• Bibliotecas
– Mais controle no
versionamento de bibliotecas

45. Complexidade Operacional

46. Complexidade Operacional
• Produtividade
– Para algumas equipes pode ser
um fardo que mina a
produtividade
• Tensão
– Pequenos módulos
independentes e implantações
rápidas traz uma pressão
adicional para operação
• Agilidade
– É praticamente impossível
garantir um ambiente
operacional de dezenas de
serviços sem automação
• Responsabilidade
– A uma tendência da
complexidade subir para a
camada de interconexões dos
serviços
• Skills e Ferramentas
– Requer algumas competências,
habilidades e ferramental
• Colaboração
– Introduzir uma cultura DevOps:
uma maior colaboração entre
os desenvolvedores, operações
e pessoal de infraestrutura

47. Complexidade Operacional

48. Application #1 Application #2
Application #3 Application #n
Cenário
Inicial - pós adoção de
microservices
Microservice #1 Microservice #2 Microservice #n
Banco Relacional Documentos Key/Store Data Base
REST API REST API REST API
API Gateway

49. API Gateway
Service aggregation
Rate Limiting
Monitoring & Alerts
Authentication Models
Policy Enforcement
Exception handling
Analytics on API Consumption
Endereça questões como: Atenção:
Não despreze a latência
Gateway não resolve tudo mas
ajuda em várias questões não
funcionaisRate Limiting Policy
JSON Threat Policy
Payload Size Policy
IP Filtering Policy

50. Obrigado!

51. Fábio Rosato
fabio.rosato@sensedia.com
@frosato
www.slideshare.net/frosato/
Vantagens e desvantagens de uma
arquitetura microservices