Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop

1,155 views

Published on

Apresentação feita na RubyConf Brazil 2012.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,155
On SlideShare
0
From Embeds
0
Number of Embeds
30
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop

  1. 1. Unindo mundos –Arquitetura orientada a serviços em Ruby e Java Maurício Linhares
  2. 2. WHO?Software Developer da OfficeDrop.com@mauriciojrhttps://github.com/mauricio
  3. 3. SOA não é ruim, asimplementações da idéia que são um desastre
  4. 4. SOA é construir aplicações independentes, quefazem uma coisa bem e delegam o que não sabem pra outros Lembra de alguma coisa?
  5. 5. Write programs that do one thing and do it well. Write programs to worktogether. Write programs to handle text streams because it is an universal interface. Doug Mcllroy – The UNIX philosophy
  6. 6. Blame themessenger, not the message
  7. 7. Aplicação Rails antiga(2.x), grande, com uma equipe crescente trabalhando nela
  8. 8. Rodar todos os testes dava uma preguiça…
  9. 9. Usávamos o banco de dados como fila
  10. 10. Longos períodos de QA
  11. 11. Tudo acontece num sólugar, numa aplicação única, onde todostrabalham o dia inteiro Por Que?
  12. 12. Como resolver isso?
  13. 13. Ah, o divórcio!
  14. 14. As duas zonasGestão de Documentos Processamento de Documentos
  15. 15. Gerenciar documentos fica nawebapp, processamento de documentos migra para uma nova aplicação
  16. 16. Se é uma nova aplicação, podemos escolher uma outra tecnologia? Comointegrar as duas apps?
  17. 17. resque como fila de trabalhosnosso fork do jesque em - https://github.com/mauricio/jesque
  18. 18. API REST com JSON para comunicação
  19. 19. S3 para armazenamento de resultados
  20. 20. Cliente envia arquivo para app servers Worker sinaliza que o arquivo foi processado Worker aceita o trabalho
  21. 21. Funcionou?
  22. 22. As duas aplicaçõespassaram a evoluir em separado
  23. 23. O backend tinha ciclos de deployment mais curtos, que nãoafetavam a aplicação web Lembre-se, fila do resque e interface REST
  24. 24. Menos código na aplicação websignificava menos testes sendo rodados Quem estava lá não se preocupava mais com backend
  25. 25. Não haviam maisdependências diretas na hora de um release, se os contratos fossemhonrados, as aplicações funcionavam
  26. 26. Mensagens auto-contidas – o backend recebe tudo o queprecisa na mensagem
  27. 27. WHERE DID WE
  28. 28. Ter aplicações separadas trouxe problemas de comunicação entre equipesVocê não pode esquecer que estão todos no mesmo barco
  29. 29. Nem todo mundo rodavao ambiente completo e a documentação nem sempre era atual As aplicações ainda devem ser usadas em conjunto
  30. 30. A implementação doJesque é enrolada e não podemos usar plugins facilmente
  31. 31. API pública e APIprivada não devem ser misturadas
  32. 32. Ter várias aplicaçõescom vários ambientes diferentes complica deployments emontagem de equipes
  33. 33. O que aprendemos?
  34. 34. Construa aplicaçõespequenas e focadas em algum trabalho
  35. 35. Só compartilhe dados pela API, não usebancos de dados pra isso.
  36. 36. Defina o que cadaaplicação deve fazer claramente
  37. 37. Crie uma interfacemínima somente com oque está sendo utilizado agora
  38. 38. Não misture arepresentação de saída com os seus modelos!Procure soluções como o Roar - https://github.com/apotonick/roar
  39. 39. Separe fontes/bancos de dados. A escalabilidade agradece.
  40. 40. Planeje e construa para falhas
  41. 41. Construa para falhar
  42. 42. Rails Engines? Será?
  43. 43. Onde nós estamos hoje?
  44. 44. Front-end HTMLmigrando pra outra aplicação
  45. 45. Cluster com auto-scaling e independente de ambiente para o backend a caminho
  46. 46. ELES DISSERAM QUE SOA ERA RUIM NÃO DIZEM MAIS
  47. 47. FIMObrigado a todos 

×