Micro serviços como ferramenta de inovação

153 visualizações

Publicada em

Quais os prós e contras na escolha de uma arquitetura? Quais os impactos na produtividade das equipes envolvidas?

Publicada em: Software
  • Seja o primeiro a comentar

Micro serviços como ferramenta de inovação

  1. 1. MICRO SERVIÇOS UTOPIA OU DISTOPIA? COMO FERRAMENTA DE INOVAÇÃO
  2. 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. 3. Resumo ● Conceitos básicos ● Problemas técnicos ● Quando a conta fecha? ● Minha visão TÓPICOS
  4. 4. Resumo ● Conceitos básicos ● Problemas técnicos ● Quando a conta fecha? ● Minha visão TÓPICOS
  5. 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. 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. 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. 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. 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. 10. Resumo ● Conceitos básicos ● Problemas técnicos ● Quando a conta fecha? ● Minha visão TÓPICOS
  11. 11. Site de reserva de quartos de hotel Problemas Técnicos ESTUDO DE CASO FICTÍCIO
  12. 12. Caso de uso: listar comentários que amigos fizeram sobre um determinado hotel. Problemas Técnicos ESTUDO DE CASO FICTÍCIO
  13. 13. Problemas Técnicos ESTUDO DE CASO FICTÍCIO Solução implementada como monolito
  14. 14. Problemas Técnicos ESTUDO DE CASO FICTÍCIO Implementação como micro serviços versão 1.0
  15. 15. FALHA DE SEGURANÇA
  16. 16. Problemas Técnicos ESTUDO DE CASO FICTÍCIO Qualquer um com acesso interno ao firewall ainda pode explorar falhas de segurança.
  17. 17. Problemas Técnicos ESTUDO DE CASO FICTÍCIO Implementação como micro serviços versão 2.0
  18. 18. 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?
  19. 19. Problemas Técnicos ASPECTOS NÃO FUNCIONAIS ● Performance ● Disponibilidade ● Escalabilidade
  20. 20. Problemas Técnicos LEI DE LITTLE U = V x T Usuários simultâneos Vazão Tempo de resposta
  21. 21. Problemas Técnicos LEI DE LITTLE U = V x T Usuários simultâneos Tempo de resposta Vazão Independe da aplicação
  22. 22. 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
  23. 23. 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.
  24. 24. Problemas Técnicos ASPECTOS NÃO FUNCIONAIS Qual o real impacto de uma requisição via HTTP pela rede?
  25. 25. Qual o real custo da resolução de nome?
  26. 26. Origem: Virgínia, EUA ● Média: 117 ms ● Mediana: 111 ms
  27. 27. Qual o real impacto do controle de congestionamento (habilitado por padrão)?
  28. 28. https://blogs.msdn.microsoft.com/windowsazurestorage/2010/06/25/nagles-algorithm-is-not-friendly-towards-small-requests/
  29. 29. Pode haver retentativas, perdas de pacotes, etc, que diminuem a velocidade percebida
  30. 30. Problemas Técnicos ASPECTOS NÃO FUNCIONAIS Como a arquitetura de micro serviços afeta a disponibilidade e escalabilidade?
  31. 31. 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
  32. 32. 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
  33. 33. Problemas Técnicos Disponibilidade Exemplo: Serviço hospedado em 2 servidores mas precisa de apenas 1 para atender demanda
  34. 34. Problemas Técnicos Disponibilidade Exemplo: Serviço A depende dos serviços B e C para funcionar corretamente
  35. 35. Problemas Técnicos Disponibilidade Um pouco de matemática...
  36. 36. 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 é:
  37. 37. 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 é:
  38. 38. 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! +
  39. 39. P(S) = 0.9997 Exemplo numérico: ● p = 0.99 ● k = 2 ● n = 3
  40. 40. P(C) = P(S) x Disponibilidade de um caso de uso C que depende de x serviços executando corretamente: i = 1 i
  41. 41. 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
  42. 42. 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
  43. 43. http://samnewman.io/talks/principles-of-microservices/
  44. 44. http://samnewman.io/talks/principles-of-microservices/ Imposições de Micro Serviços
  45. 45. 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
  46. 46. 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:
  47. 47. “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."
  48. 48. Resumo ● Conceitos básicos ● Problemas técnicos ● Quando a conta fecha? ● Minha visão TÓPICOS
  49. 49. Quando a Conta Fecha? ANÁLISE DE CENÁRIOS
  50. 50. Não Vale a Pena! ANÁLISE DE CENÁRIOS - I ● Pouca evolução funcional e não funcional ● Equipe pequena ou média
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 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
  56. 56. Quando a Conta Fecha? EXERCíCIO DE IMAGINAÇÃO
  57. 57. 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
  58. 58. Quando a Conta Fecha? EXERCíCIO DE IMAGINAÇÃO Mais um pouco de matemática...
  59. 59. 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:
  60. 60. 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.
  61. 61. 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)
  62. 62. 0.8 x 5 4 Exemplo numérico: ● T(1) = 5 ● n = 4 ● P = 0.8 T(n) = + (0.2) x 5
  63. 63. Exemplo numérico: ● T(1) = 5 ● n = 4 ● P = 0.8 T(n) = 2
  64. 64. T(1) T(n) Quanto uma equipe com n desenvolvedores produz a mais do que uma equipe com 1 desenvolvedor? S(n) =
  65. 65. 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
  66. 66. Quando a Conta Fecha? ANÁLISE DE CENÁRIOS - IV ● Equipe pequena ou média ● Rápida evolução funcional ● Quantidade substancial de investimentos
  67. 67. Quando a Conta Fecha? ANÁLISE DE CENÁRIOS - V ● Equipe muito grande ● Alguma evolução funcional ● Alguma evolução não funcional
  68. 68. 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.
  69. 69. ● Conceitos básicos ● Problemas técnicos ● Quando a conta fecha? ● Minha visão TÓPICOS Resumo
  70. 70. Minha Visão SE FOR A ESCOLHA ERRADA ● Aumento do custo do projeto ● Aumento do custo de infra ● Pior performance ● Sistema mais instável
  71. 71. 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
  72. 72. 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
  73. 73. 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
  74. 74. ● Email: pedrohenriquesimoesdeoliveira@gmail.com ● Blog técnico da Direct Talk: http://www.directtalk.com.br/tech CONTATOS PARA CONVERSARMOS MAIS
  75. 75. OBRIGADO!

×