Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop


Published on

Presentation done at RubyConf Brazil 2012.

Published in: Technology
  • Be the first to comment

Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop

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