micro serviços como ferramenta de inovação
TRANSCRIPT
MICRO SERVIÇOS
UTOPIAOU
DISTOPIA?
COMO FERRAMENTA DE INOVAÇÃO
SobreMim
● Arquiteto de Sistemas na Direct Talk
● +4 anos utilizando micro serviços
● +5 anos utilizando AWS em produção
● Experiência prévia em portal de
internet e desenvolvendo software para
mercado financeiro
PEDRO HENRIQUE SIMÕES DE OLIVEIRA
Resumo● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS
Resumo● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS
ConceitosBásicos
Sistema que implementa um conjunto
de funcionalidades e se comunica com
o mundo exterior através de uma
interface bem definida.
SERVIÇO
ConceitosBásicos
Arquitetura de sistemas que adota
como abordagem principal para
resolução de problemas a utilização de
serviços que se comunicam.
ARQUITETURA ORIENTADA A SERVIÇOS (SOA)
Serviço que implementa um conjunto
de funcionalidades fortemente
relacionadas. Um resultado colateral é
que o serviço fica menor, daí o nome.
ConceitosBásicos
MICRO SERVIÇO
Serviço que usualmente implementa
uma única função. Ganhando tração
por conta das ofertas de nuvem. Ex.:
Azure Cloud Functions, AWS Lambda,
Google Cloud Function.
ConceitosBásicos
NANO SERVIÇO (SERVERLESS)
Termo bastante abusado.
Normalmente relacionado a uma
aplicação ou serviço que mesmo que
seja modularizado do ponto de vista de
código, é implantado como um só
software. Geralmente é um sistema
complexo.
ConceitosBásicos
MONOLITO
Resumo● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS
Site de reserva de quartos de hotel
ProblemasTécnicos
ESTUDO DE CASO FICTÍCIO
Caso de uso: listar comentários que
amigos fizeram sobre um determinado
hotel.
ProblemasTécnicos
ESTUDO DE CASO FICTÍCIO
ProblemasTécnicos
ESTUDO DE CASO FICTÍCIO
Solução implementada como monolito
ProblemasTécnicos
ESTUDO DE CASO FICTÍCIO
Implementação como micro serviços
versão 1.0
FALHA DE SEGURANÇA
ProblemasTécnicos
ESTUDO DE CASO FICTÍCIO
Qualquer um com acesso interno ao
firewall ainda pode explorar falhas de
segurança.
ProblemasTécnicos
ESTUDO DE CASO FICTÍCIO
Implementação como micro serviços
versão 2.0
ProblemasTécnicos
ESTUDO DE CASO FICTÍCIO
Como uma solução de micro serviços
se compara com uma solução monolito
em aspectos não funcionais?
ProblemasTécnicos
ASPECTOS NÃO FUNCIONAIS
● Performance
● Disponibilidade
● Escalabilidade
ProblemasTécnicos
LEI DE LITTLE
U = V x T
Usuários
simultâneos
Vazão
Tempo de
resposta
ProblemasTécnicos
LEI DE LITTLE
U = V x T
Usuários
simultâneos
Tempo de
resposta
Vazão
Independe da
aplicação
ProblemasTécnicos
LEI DE LITTLE
U = V x T
Usuários
simultâneos
Vazão
Tempo de
resposta
Requisições pela rede já
garantem aumento do tempo
ProblemasTécnicos
ASPECTOS NÃO FUNCIONAIS
● Traduções diretas de monolito
para micro serviços normalmente
implicam em queda de
performance;
● Serviços centrais correm risco de
virar hotspots. Ex.: 1 requisição de
usuário vira 3 requisições para o
Autenticador.
ProblemasTécnicos
ASPECTOS NÃO FUNCIONAIS
Qual o real impacto de uma requisição
via HTTP pela rede?
Qual o real custo da
resolução de nome?
Origem: Virgínia, EUA
● Média: 117 ms
● Mediana: 111 ms
Qual o real impacto do
controle de
congestionamento
(habilitado por padrão)?
https://blogs.msdn.microsoft.com/windowsazurestorage/2010/06/25/nagles-algorithm-is-not-friendly-towards-small-requests/
Pode haver retentativas,
perdas de pacotes, etc, que
diminuem a velocidade
percebida
ProblemasTécnicos
ASPECTOS NÃO FUNCIONAIS
Como a arquitetura de micro serviços
afeta a disponibilidade e
escalabilidade?
ProblemasTécnicos
Disponibilidade
A disponibilidade de um serviço está
limitada a disponibilidade do
hardware. O fornecedor de hardware
(ou de solução de nuvem)
normalmente informa esse valor
ProblemasTécnicos
Disponibilidade
Um sistema para ser considerado de
alta disponibilidade precisa executar
em pelo menos 1 nó a mais do que o
necessário para atender o tráfego
(redundância), executando atrás de um
load balancer
ProblemasTécnicos
Disponibilidade
Exemplo: Serviço hospedado em 2
servidores mas precisa de apenas 1 para
atender demanda
ProblemasTécnicos
Disponibilidade
Exemplo: Serviço A depende dos
serviços B e C para funcionar
corretamente
ProblemasTécnicos
Disponibilidade
Um pouco de matemática...
P(S) = Σ ( ) (1 - p)p n - iinn
i i = k
● Disponibilidade de um nó: p
● Mínimo de nós para atender a demanda: k
● Total de nós executando o serviço: n
Disponibilidade do serviço S é:
P(S) = Σ (1 - p)p n - iin!n
(n - i)!i! i = k
● Disponibilidade de um nó: p
● Mínimo de nós para atender a demanda: k
● Total de nós executando o serviço: n
Disponibilidade do serviço S é:
P(S) =
Exemplo numérico:
● p = 0.99
● k = 2
● n = 3
(0.01)0.99 123! 1!2!
(0.01)0.99 033!0!3!
+
P(S) = 0.9997
Exemplo numérico:
● p = 0.99
● k = 2
● n = 3
P(C) = P(S)x
Disponibilidade de um caso de uso C que depende de x
serviços executando corretamente:
i = 1
i
ProblemasTécnicos
ANÁLISE MAIS COMPLEXA
● Servidor 99% de disponibilidade;
● Todo serviço que precisa de n
servidores para atender a demanda
está rodando em n + 1 servidores
● Todas as dependências vão utilizar
o mesmo número de serviços
ProblemasTécnicos
CONCLUSÕES
Para alcançar ou superar os requisitos
não funcionais de uma solução
utilizando arquitetura monolítica, uma
mudança dramática na forma de como
desenvolver é necessária
http://samnewman.io/talks/principles-of-microservices/
http://samnewman.io/talks/principles-of-microservices/
Imposições de
Micro Serviços
ProblemasTécnicos
CUSTOS EXTRAS
● Complexidade de configuração
● Complexidade de deploy
● Serviços consomem recursos de
hardware mesmo parados. Mais
serviços rodando (mesmo que sem
carga) implicam em maior
demanda de infraestrutura
ProblemasTécnicos
REFERÊNCIAS PARA IMPLEMENTAÇÃO
● http://microservices.io/patterns/microservices.html
● https://info.thoughtworks.com/livro-micro-servicos.html
● https://msdn.microsoft.com/en-us/library/dn568099.aspx:
“Simplicidade é
pré-requisito para
confiabilidade.”
Edsger W. Dijkstra
"Simplicidade é uma grande virtude
mas requer trabalho duro para ser
alcançada e educação para ser
apreciada. E o que é pior:
complexidade vende melhor."
Resumo● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS
Quando a Conta
Fecha?
ANÁLISE DE CENÁRIOS
Não Vale a Pena!
ANÁLISE DE CENÁRIOS - I
● Pouca evolução funcional e não
funcional
● Equipe pequena ou média
Quando a Conta
Fecha?
ANÁLISE DE CENÁRIOS - II
● Evolução funcional moderada
● Evolução não funcional moderada
● Equipe pequena ou média
Não Vale a Pena!
ANÁLISE DE CENÁRIOS - II
● Custo de desenvolver nova
funcionalidade: médio ou baixo
quando comparado com um
sistema recém-feito
Quando a Conta
Fecha?
ANÁLISE DE CENÁRIOS - III
● Evolução funcional moderada
● Evolução não funcional moderada
● Equipe pequena ou média
● Custo de adição de funcionalidades
muito alto
Quando a Conta
Fecha?
ANÁLISE DE CENÁRIOS - III
Motivadores
● Reestruturação arquitetural
gradual (rato roendo o queijo)
● Cada micro serviço pode ser visto
como um green field, acelerando a
produtividade
Quando a Conta
Fecha?
ANÁLISE DE CENÁRIOS - III
RISCOS
● Competência técnica da equipe
● Desestabilizar o sistema
● Migração pode ser muito lenta
● Quebra em micro serviços: débito
técnico X roadmap funcional
Quando a Conta
Fecha?
EXERCíCIO DE IMAGINAÇÃO
Quando a Conta
Fecha?
EXERCíCIO DE IMAGINAÇÃO
● Todos os desenvolvedores têm a
mesma produtividade
● As atividades são 100%
pré-determinadas independente da
equipe
Quando a Conta
Fecha?
EXERCíCIO DE IMAGINAÇÃO
Mais um pouco de matemática...
T(n) =
T(1)n
● T(1): tempo gasto por 1 desenvolvedor para executar uma
tarefa
● T(n): tempo gasto por n desenvolvedores para executar a
mesma tarefa
Regra de três nos diria isso:
T(n) =
T(1)n
● T(1): tempo gasto por 1 desenvolvedor para executar uma
tarefa
● T(n): tempo gasto por n desenvolvedores para executar a
mesma tarefa
Regra de três nos diria isso:
Porém nem todas as atividades são paralelizáveis.
P.T(1)n
● T(1): tempo gasto por 1 desenvolvedor para executar uma
tarefa
● T(n): tempo gasto por n desenvolvedores para executar a
mesma tarefa
● P: percentual de atividades paralelizáveis
T(n) =
+ (1 - P).T(1)
0.8 x 54
Exemplo numérico:
● T(1) = 5
● n = 4
● P = 0.8
T(n) =
+ (0.2) x 5
Exemplo numérico:
● T(1) = 5
● n = 4
● P = 0.8
T(n) = 2
T(1)T(n)
Quanto uma equipe com n desenvolvedores produz a mais do
que uma equipe com 1 desenvolvedor?
S(n) =
T(1)T(n)
Quanto uma equipe com n desenvolvedores produz a mais do
que uma equipe com 1 desenvolvedor?
S(n) =
Produtividade da equipe
Quando a Conta
Fecha?
ANÁLISE DE CENÁRIOS - IV
● Equipe pequena ou média
● Rápida evolução funcional
● Quantidade substancial de
investimentos
Quando a Conta
Fecha?
ANÁLISE DE CENÁRIOS - V
● Equipe muito grande
● Alguma evolução funcional
● Alguma evolução não funcional
Quando a Conta
Fecha?
ANÁLISE DE CENÁRIOS
Nestes cenários paralelizar o
desenvolvimento é uma necessidade. A
utilização de micro serviços é eficiente
para isso.
● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS
Resumo
Minha Visão
SE FOR A ESCOLHA ERRADA
● Aumento do custo do projeto
● Aumento do custo de infra
● Pior performance
● Sistema mais instável
Minha Visão
SE FOR A ESCOLHA CERTAIMPLEMENTADA DA FORMA ERRADA
● Aumento do custo do projeto
● Aumento do custo de infra
● Pior performance
● Sistema mais instável
Minha Visão
SE FOR A ESCOLHA CERTA IMPLEMENTADA DA FORMA CERTA
● Os benefícios só vem a longo prazo
● O custo inicial será maior que o
benefício inicial
● Visão de longo prazo dos decisores
é fundamental no processo
Minha Visão
QUAIS SÃO OS GANHOS
● Independência entre equipes
● Aumento de produtividade
● Micro serviços existentes
potencializam novos produtos
(como brincar de lego)
● Aumento de maturidade técnica
● Email:
● Blog técnico da Direct Talk:
http://www.directtalk.com.br/tech
CONTATOS
PARA CONVERSARMOS MAIS
OBRIGADO!