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.
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
√
√
√
√
√
√
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!
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)
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
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”
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
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
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
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
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
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