Your SlideShare is downloading. ×
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop

1,193
views

Published on

Presentation done at RubyConf Brazil 2012.

Presentation done at RubyConf Brazil 2012.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,193
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Service orientedarchitecture mixing Ruby and Java Maurício Linhares
  • 2. WHO?Software Developer da OfficeDrop.com@mauriciojrhttps://github.com/mauricio
  • 3. SOA isn’t bad, theimplementations we getfrom hungry consultants are
  • 4. SOA is building independent apps that do one thing well andleave everything else to others Feels like something you have heard before?
  • 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. Blame themessenger, not the message
  • 7. Old Rails app (2.x), large, with agrowing team working on it
  • 8. Running all tests took too long…
  • 9. We used the database as a queue
  • 10. We had long QA periods
  • 11. Everything happens in a single app, whereeveryone change code Why?
  • 12. How can we solve this?
  • 13. Ah, the divorce!
  • 14. Two zones Documents managementDocuments processing
  • 15. Documents management stays onthe webapp, processingdocuments migrates to a new app
  • 16. If it’s a new app, can we change technology? How do we integrate both?
  • 17. resque as our work queueour jesque fork is at - https://github.com/mauricio/jesque
  • 18. API REST with JSON for communication
  • 19. S3 to store the results
  • 20. Client sends a file to the app server Worker signals that it has finished the job A worker accepts the job
  • 21. Did it work?
  • 22. The two apps startedevolving in separate
  • 23. The backend systemstarted to have smaller cycles, independent ofthe webapp, with many deploys a day
  • 24. Less code meant thatthere were less tests to be runThe backend didn’t have to run webapp tests, the webapp didn’t have to run the backend tests
  • 25. There were no directdependencies between the apps, they didn’t have to be deployed together anymore
  • 26. Auto-contained messages – the backend had allinformation needed at the message level
  • 27. WHERE DID WE
  • 28. Separate applications caused communication problems between the teamsWe’re all on the same boat, open the discussion of stuff that affects both ends
  • 29. Not everyone did run all apps and the documentation wasn’t always up to date
  • 30. Jesque’s code isn’t assimple as it could be and most of the resque plugins are of no use
  • 31. Public and private API’s should not be mixed. Make sure they’re completely separate.
  • 32. Many apps in different environments will complicate yourdeployment and team building
  • 33. What did we learn?
  • 34. Build small, focused apps
  • 35. All communicationshould be done over the API and from nowhere else
  • 36. Define clearly what each application should do
  • 37. Create a minimalcommunication interfacewith that you need today. It will change.
  • 38. Don’t mix modelrepresentation with your model codeLook for solutions like Roar - https://github.com/apotonick/roar
  • 39. Separe fontes/bancos de Separatedatabases/datasources for the different apps
  • 40. Plan and build stuff expecting failure
  • 41. Build to fail
  • 42. Rails Engines? Maybe?
  • 43. Where are we today?
  • 44. HTML5 front end independent of thecurrent webapp, all API based
  • 45. Auto-scaling cluster and independent of the environment for the backend is on the way
  • 46. THEY SAID SOA WAS BADTHEY DON’T SAY IT ANYMORE
  • 47. THE ENDThank You 

×