Upload
mauricio-linhares
View
1.218
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Presentation done at RubyConf Brazil 2012.
Citation preview
Service oriented architecture mixing
Ruby and JavaMaurício Linhares
WHO?
Software Developer da OfficeDrop.com
@mauriciojr
https://github.com/mauricio
SOA isn’t bad, the implementations we
get from hungry consultants are
SOA is building independent apps
that do one thing well and leave everything
else to othersFeels like something you have heard before?
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
Blame the messenger, not the
message
Old Rails app (2.x), large, with a growing team working on it
Running all tests took too long…
We used the database as a queue
We had long QA periods
Everything happens in a single app, where
everyone change code
Why?
How can we solve this?
Ah, the divorce!
Two zones
Documents management
Documents processing
Documents management stays
on the webapp, processing
documents migrates to a new app
If it’s a new app, can we change
technology? How do we integrate both?
resque as our work queue
our jesque fork is at - https://github.com/mauricio/jesque
API REST with JSON for communication
S3 to store the results
Client sends a file to the app server
Processing message is sent to the queue
A worker accepts the job
Worker signals that it has finished the job
Did it work?
The two apps started evolving in separate
The backend system started to have smaller cycles,
independent of the webapp, with many
deploys a day
Less code meant that there were less tests
to be runThe backend didn’t have to run webapp tests, the webapp
didn’t have to run the backend tests
There were no direct dependencies
between the apps, they didn’t have to
be deployed together anymore
Auto-contained messages – the backend had all
information needed at the message level
WHERE DID WE
Separate applications caused
communication problems between
the teamsWe’re all on the same boat, open the discussion of stuff
that affects both ends
Not everyone did run all apps and the documentation
wasn’t always up to date
Jesque’s code isn’t as simple as it could be
and most of the resque plugins are of
no use
Public and private API’s should not be mixed. Make sure they’re completely
separate.
Many apps in different
environments will complicate your deployment and team building
What did we learn?
Build small, focused apps
All communication should be done over
the API and from nowhere else
Define clearly what each application
should do
Create a minimal communication
interface with that you need today. It will
change.
Don’t mix model representation with
your model codeLook for solutions like Roar - https://github.com/apotonick/
roar
Separe fontes/bancos de Separate
databases/datasources for the different
apps
Plan and build stuff expecting failure
Build to fail
Rails Engines? Maybe?
Where are we today?
HTML5 front end independent of the current webapp, all
API based
Auto-scaling cluster and independent of the environment for
the backend is on the way
THEY SAID SOA WAS BAD
THEY DON’T SAY IT ANYMORE
THE ENDThank You