Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
•Download as PPTX, PDF•
1 like•1,506 views
Service oriented architecture mixing Ruby and Java can provide benefits by separating applications into independent components that communicate over APIs. The document discusses a case where splitting a monolithic Rails application into separate document management and processing apps improved development by allowing independent deployment and reduced test time. Key aspects that enabled this included using Resque for job queuing between apps, RESTful JSON APIs, and storing processed files in S3. However, clear documentation and coordination were needed to integrate the separate teams working on each app.
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
- 1. Service oriented architecture mixing Ruby and Java Maurício Linhares
- 2. WHO? Software Developer da OfficeDrop.com @mauriciojr https://github.com/mauricio
- 4. SOA isn’t bad, the implementations we get from hungry consultants are
- 5. SOA is building independent apps that do one thing well and leave everything else to others Feels like something you have heard before?
- 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. Old Rails app (2.x), large, with a growing team working on it
- 10. Running all tests took too long…
- 11. We used the database as a queue
- 12. We had long QA periods
- 13. Everything happens in a single app, where everyone change code Why?
- 14. How can we solve this?
- 15. Ah, the divorce!
- 16. Two zones Documents management Documents processing
- 17. Documents management stays on the webapp, processing documents migrates to a new app
- 18. If it’s a new app, can we change technology? How do we integrate both?
- 19. resque as our work queue our jesque fork is at - https://github.com/mauricio/jesque
- 20. API REST with JSON for communication
- 21. S3 to store the results
- 22. Client sends a file to the app server Worker signals that it has finished the job A worker accepts the job
- 23. Did it work?
- 24. The two apps started evolving in separate
- 25. The backend system started to have smaller cycles, independent of the webapp, with many deploys a day
- 26. Less code meant that there were less tests to be run The backend didn’t have to run webapp tests, the webapp didn’t have to run the backend tests
- 27. There were no direct dependencies between the apps, they didn’t have to be deployed together anymore
- 28. Auto-contained messages – the backend had all information needed at the message level
- 29. WHERE DID WE
- 30. Separate applications caused communication problems between the teams We’re all on the same boat, open the discussion of stuff that affects both ends
- 31. Not everyone did run all apps and the documentation wasn’t always up to date
- 32. Jesque’s code isn’t as simple as it could be and most of the resque plugins are of no use
- 33. Public and private API’s should not be mixed. Make sure they’re completely separate.
- 34. Many apps in different environments will complicate your deployment and team building
- 35. What did we learn?
- 36. Build small, focused apps
- 37. All communication should be done over the API and from nowhere else
- 38. Define clearly what each application should do
- 39. Create a minimal communication interface with that you need today. It will change.
- 40. Don’t mix model representation with your model code Look for solutions like Roar - https://github.com/apotonick/roar
- 41. Separe fontes/bancos de Separate databases/datasources for the different apps
- 42. Plan and build stuff expecting failure
- 43. Build to fail
- 45. Where are we today?
- 46. HTML5 front end independent of the current webapp, all API based
- 47. Auto-scaling cluster and independent of the environment for the backend is on the way
- 48. THEY SAID SOA WAS BAD THEY DON’T SAY IT ANYMORE
- 49. THE END Thank You