O documento discute os conceitos básicos de micro serviços e arquitetura orientada a serviços, e analisa quando a abordagem de micro serviços pode ser apropriada versus uma arquitetura monolítica. O autor destaca que micro serviços podem aumentar a complexidade e custos em certos cenários, e que é importante considerar aspectos como tamanho da equipe, necessidade de escalabilidade e evolução do produto ao decidir entre as abordagens.

1. MICRO SERVIÇOS
UTOPIA
OU
DISTOPIA?
COMO FERRAMENTA DE INOVAÇÃO

2. Sobre
Mim
● 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

3. Resumo
● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS

4. Resumo
● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS

5. Conceitos
Básicos
Sistema que implementa um conjunto
de funcionalidades e se comunica com
o mundo exterior através de uma
interface bem definida.
SERVIÇO

6. Conceitos
Bá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)

7. Serviço que implementa um conjunto
de funcionalidades fortemente
relacionadas. Um resultado colateral é
que o serviço fica menor, daí o nome.
Conceitos
Básicos
MICRO SERVIÇO

8. 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.
Conceitos
Básicos
NANO SERVIÇO (SERVERLESS)

9. 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.
Conceitos
Básicos
MONOLITO

10. Resumo
● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS

11. Site de reserva de quartos de hotel
Problemas
Técnicos
ESTUDO DE CASO FICTÍCIO

12. Caso de uso: listar comentários que
amigos fizeram sobre um determinado
hotel.
Problemas
Técnicos
ESTUDO DE CASO FICTÍCIO

13. Problemas
Técnicos
ESTUDO DE CASO FICTÍCIO
Solução implementada como monolito

15. Problemas
Técnicos
ESTUDO DE CASO FICTÍCIO
Implementação como micro serviços
versão 1.0

17. FALHA DE
SEGURANÇA

19. Problemas
Técnicos
ESTUDO DE CASO FICTÍCIO
Qualquer um com acesso interno ao
firewall ainda pode explorar falhas de
segurança.

20. Problemas
Técnicos
ESTUDO DE CASO FICTÍCIO
Implementação como micro serviços
versão 2.0

22. Problemas
Té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?

23. Problemas
Técnicos
ASPECTOS NÃO FUNCIONAIS
● Performance
● Disponibilidade
● Escalabilidade

24. Problemas
Técnicos
LEI DE LITTLE
U = V x T
Usuários
simultâneos Vazão
Tempo de
resposta

25. Problemas
Técnicos
LEI DE LITTLE
U = V x T
Usuários
simultâneos
Tempo de
resposta
Vazão
Independe da
aplicação

26. Problemas
Té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

27. Problemas
Té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.

28. Problemas
Técnicos
ASPECTOS NÃO FUNCIONAIS
Qual o real impacto de uma requisição
via HTTP pela rede?

30. Qual o real custo da
resolução de nome?

31. Origem: Virgínia, EUA
● Média: 117 ms
● Mediana: 111 ms

33. Qual o real impacto do
controle de
congestionamento
(habilitado por padrão)?

34. https://blogs.msdn.microsoft.com/windowsazurestorage/2010/06/25/nagles-algorithm-is-not-friendly-towards-small-requests/

36. Pode haver retentativas,
perdas de pacotes, etc, que
diminuem a velocidade
percebida

37. Problemas
Técnicos
ASPECTOS NÃO FUNCIONAIS
Como a arquitetura de micro serviços
afeta a disponibilidade e
escalabilidade?

38. Problemas
Té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

39. Problemas
Té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

40. Problemas
Técnicos
Disponibilidade
Exemplo: Serviço hospedado em 2
servidores mas precisa de apenas 1 para
atender demanda

42. Problemas
Técnicos
Disponibilidade
Exemplo: Serviço A depende dos
serviços B e C para funcionar
corretamente

44. Problemas
Técnicos
Disponibilidade
Um pouco de matemática...

45. P(S) = Σ ( ) (1 - p)p n - iin
n
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 é:

46. 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 é:

47. 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!
+

48. P(S) = 0.9997
Exemplo numérico:
● p = 0.99
● k = 2
● n = 3

49. P(C) = P(S)
x
Disponibilidade de um caso de uso C que depende de x
serviços executando corretamente:
i = 1
i

50. Problemas
Té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

52. Problemas
Té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

53. http://samnewman.io/talks/principles-of-microservices/

54. http://samnewman.io/talks/principles-of-microservices/
Imposições de
Micro Serviços

55. Problemas
Té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

56. Problemas
Té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:

57. “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."

58. Resumo
● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS

59. Quando a
Conta
Fecha?
ANÁLISE DE CENÁRIOS

60. Não
Vale a
Pena!
ANÁLISE DE CENÁRIOS - I
● Pouca evolução funcional e não
funcional
● Equipe pequena ou média

61. 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

62. 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

63. 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

64. 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

65. 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

66. Quando a
Conta
Fecha?
EXERCíCIO DE IMAGINAÇÃO

67. 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

68. Quando a
Conta
Fecha?
EXERCíCIO DE IMAGINAÇÃO
Mais um pouco de matemática...

69. 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:

70. 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.

71. 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)

72. 0.8 x 5
4
Exemplo numérico:
● T(1) = 5
● n = 4
● P = 0.8
T(n) =
+ (0.2) x 5

73. Exemplo numérico:
● T(1) = 5
● n = 4
● P = 0.8
T(n) = 2

74. T(1)
T(n)
Quanto uma equipe com n desenvolvedores produz a mais do
que uma equipe com 1 desenvolvedor?
S(n) =

75. 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

77. Quando a
Conta
Fecha?
ANÁLISE DE CENÁRIOS - IV
● Equipe pequena ou média
● Rápida evolução funcional
● Quantidade substancial de
investimentos

78. Quando a
Conta
Fecha?
ANÁLISE DE CENÁRIOS - V
● Equipe muito grande
● Alguma evolução funcional
● Alguma evolução não funcional

79. 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.

80. ● Conceitos básicos
● Problemas técnicos
● Quando a conta fecha?
● Minha visão
TÓPICOS
Resumo

81. Minha
Visão
SE FOR A ESCOLHA ERRADA
● Aumento do custo do projeto
● Aumento do custo de infra
● Pior performance
● Sistema mais instável

82. Minha
Visão
SE FOR A ESCOLHA CERTA
IMPLEMENTADA DA FORMA ERRADA
● Aumento do custo do projeto
● Aumento do custo de infra
● Pior performance
● Sistema mais instável

83. 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

84. 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

85. ● Email:
pedrohenriquesimoesdeoliveira@gmail.com
● Blog técnico da Direct Talk:
http://www.directtalk.com.br/tech
CONTATOS
PARA CONVERSARMOS MAIS

86. OBRIGADO!