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

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

1.138 visualizações

Publicada em

Apresentação feita na RubyConf Brazil 2012.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.138
No SlideShare
0
A partir de incorporações
0
Número de incorporações
30
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no 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 

×