Acelerando Sistemas Distribuídos

420 views

Published on

5° Rs On Rails - Acelerando Sistemas Distribuídos

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
420
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
6
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Acelerando Sistemas Distribuídos

  1. 1. Acelerando Sistemas Distribuídos
  2. 2. @johalf e @spiceee
  3. 3. # onrails
  4. 4. SOA
  5. 5. Sistema Distribuído
  6. 6. “Um sistema distribuído consiste em múltiplas aplicações autônomas que interagem para atingir uma meta comum”
  7. 7. “Um sistema distribuído consiste em múltiplas aplicações autônomas que interagem para atingir uma meta comum” Wolfgang Emmerich
  8. 8. “Afirmar que um sistema distribuído funciona com uma meta comum num ambiente aberto como a Internet é algo difícil.”
  9. 9. “Afirmar que um sistema distribuído funciona com uma meta comum num ambiente aberto como a Internet é algo difícil.” Roy Fielding
  10. 10. Por que sistema distribuído?
  11. 11. Prós
  12. 12. Desacoplamento
  13. 13. Desacoplamento de responsabilidade, de domínio, de arquitetura, de classes, de código
  14. 14. Db não é API
  15. 15. Db não é API difícil manter contratos e regras de negócio
  16. 16. Escalabilidade
  17. 17. Disponibilidade
  18. 18. Performance
  19. 19. Custo
  20. 20. Contras
  21. 21. Logs
  22. 22. Testes
  23. 23. Deploy
  24. 24. Granularidade
  25. 25. Versionamento
  26. 26. Segurança/Auth
  27. 27. ENV=development
  28. 28. Latência
  29. 29. Complexidade
  30. 30. Arquitetura distribuída do iba
  31. 31. Toolbox
  32. 32. + Resque
  33. 33. “why so slow?”
  34. 34. “why so slow?” The Armin
  35. 35. custo do REST
  36. 36. Granularidade (again)
  37. 37. Filters, group-bys
  38. 38. Meta comum?
  39. 39. “Faster, faster, faster, now!”
  40. 40. “Faster, faster, faster, now!” The Armin
  41. 41. Cacheia tudo!
  42. 42. “Need more memcache!”
  43. 43. “Need more memcache!” The Armin
  44. 44. Varnish + ETag + fragment caching
  45. 45. Invalidação de cache = uma das coisas mais difíceis blah blah
  46. 46. Difícil customizar por usuário
  47. 47. Rethink
  48. 48. API
  49. 49. API Eager loading de entidades que compoem uma unidade de informação
  50. 50. API
  51. 51. API O cliente escolhe o nível de detalhes que precisa
  52. 52. Um passo para trás: unificar alguns serviços
  53. 53. Um passo para trás: unificar alguns serviços Analisamos serviços que poderiam ser acoplados sem grande impacto à plataforma
  54. 54. Preconsume
  55. 55. Preconsume Colocar a informação numa camada de custo mais baixo de obtenção
  56. 56. App Server
  57. 57. App Server Buscar um app server que se adaptasse melhor ao nosso stack
  58. 58. CAB: Cache Against Boiada
  59. 59. CAB: Cache Against Boiada separando o tipo de cache pelo tipo de usuário
  60. 60. “Venha me ler todinha no iba”
  61. 61. Um só framework
  62. 62. Um só framework Mais de um framework num sistema distribuído requer mais manutenção
  63. 63. Eliminar concorrência entre Back-Office e User-facing
  64. 64. Eliminar concorrência entre Back-Office e User-facing o usuário querendo comprar um livro não precisa sofrer com um processo de faturamento
  65. 65. Async?
  66. 66. Async? Começar a explorar non-blocking app stacks
  67. 67. “Ah! Joga tudo no Redis”
  68. 68. “Cache vai nos salvar”
  69. 69. O MongoDB é foda! Mas depois ele cobra a conta.
  70. 70. Modelagem errada
  71. 71. Conclusão
  72. 72. Perguntas?
  73. 73. Free Stuff
  74. 74. Obrigado!

×