Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop
Transferir como PPTX, PDF1 gostou990 visualizações
O documento discute a arquitetura orientada a serviços em Ruby e Java, descrevendo como o autor dividiu uma grande aplicação Rails monolítica em duas aplicações separadas para gestão de documentos e processamento de documentos, comunicando-se via fila de mensagens e API REST. Isso trouxe benefícios como ciclos de deploy mais curtos e menos testes, porém também desafios de comunicação entre equipes. O autor conclui recomendando aplicações pequenas e focadas, compartilhando dados apenas via API.
Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop
- 1. Unindo mundos – Arquitetura orientada a serviços em Ruby e Java Maurício Linhares
- 2. WHO? Software Developer da OfficeDrop.com @mauriciojr https://github.com/mauricio
- 4. SOA não é ruim, as implementações da idéia que são um desastre
- 5. SOA é construir aplicações independentes, que fazem uma coisa bem e delegam o que não sabem pra outros Lembra de alguma coisa?
- 6. Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams because it is an universal interface. Doug Mcllroy – The UNIX philosophy
- 7. Blame the messenger, not the message
- 9. Aplicação Rails antiga (2.x), grande, com uma equipe crescente trabalhando nela
- 10. Rodar todos os testes dava uma preguiça…
- 11. Usávamos o banco de dados como fila
- 12. Longos períodos de QA
- 13. Tudo acontece num só lugar, numa aplicação única, onde todos trabalham o dia inteiro Por Que?
- 15. Ah, o divórcio!
- 16. As duas zonas Gestão de Documentos Processamento de Documentos
- 17. Gerenciar documentos fica na webapp, processamento de documentos migra para uma nova aplicação
- 18. Se é uma nova aplicação, podemos escolher uma outra tecnologia? Como integrar as duas apps?
- 19. resque como fila de trabalhos nosso fork do jesque em - https://github.com/mauricio/jesque
- 20. API REST com JSON para comunicação
- 21. S3 para armazenamento de resultados
- 22. Cliente envia arquivo para app servers Worker sinaliza que o arquivo foi processado Worker aceita o trabalho
- 23. Funcionou?
- 24. As duas aplicações passaram a evoluir em separado
- 25. O backend tinha ciclos de deployment mais curtos, que não afetavam a aplicação web Lembre-se, fila do resque e interface REST
- 26. Menos código na aplicação web significava menos testes sendo rodados Quem estava lá não se preocupava mais com backend
- 27. Não haviam mais dependências diretas na hora de um release, se os contratos fossem honrados, as aplicações funcionavam
- 28. Mensagens auto- contidas – o backend recebe tudo o que precisa na mensagem
- 29. WHERE DID WE
- 30. Ter aplicações separadas trouxe problemas de comunicação entre equipes Você não pode esquecer que estão todos no mesmo barco
- 31. Nem todo mundo rodava o ambiente completo e a documentação nem sempre era atual As aplicações ainda devem ser usadas em conjunto
- 32. A implementação do Jesque é enrolada e não podemos usar plugins facilmente
- 33. API pública e API privada não devem ser misturadas
- 34. Ter várias aplicações com vários ambientes diferentes complica deployments e montagem de equipes
- 36. Construa aplicações pequenas e focadas em algum trabalho
- 37. Só compartilhe dados pela API, não use bancos de dados pra isso.
- 38. Defina o que cada aplicação deve fazer claramente
- 39. Crie uma interface mínima somente com o que está sendo utilizado agora
- 40. Não misture a representação de saída com os seus modelos! Procure soluções como o Roar - https://github.com/apotonick/roar
- 41. Separe fontes/bancos de dados. A escalabilidade agradece.
- 42. Planeje e construa para falhas
- 45. Onde nós estamos hoje?
- 46. Front-end HTML migrando pra outra aplicação
- 47. Cluster com auto-scaling e independente de ambiente para o backend a caminho
- 48. ELES DISSERAM QUE SOA ERA RUIM NÃO DIZEM MAIS
- 49. FIM Obrigado a todos