Rails and Service Oriented Architecture (SOA): any downsides?

Rails
1

Hey folks,

I like what I’m reading about improved performance via Service
Oriented Architecture for my Rails app. Stepping in that direction
will require some code reorganization, though. Has anyone regretted
the time invested in Rails SOA or suffered any other drawbacks that
might – from a business perspective – have disinclined them from
going SOA?

Lille

2

One potential problem is providing satisfactory security. The
traditional security model has all the protection features built into
individual applications, but opening access to all applications as
services can and is likely to result in structural vulnerabilities. This
problem is being researched; however, the technologies are still, for
the most part, emerging.

3

Noah,

Thanks for your comment (interesting that fewer are interested in this
area.)

OK, but let’s say I have a Rails front-end – that is the web service
API and the services are behind it.

Lille

4

On 29 July 2011 16:02, Lille [email protected] wrote:

Hey folks,

I like what I’m reading about improved performance via Service
Oriented Architecture for my Rails app.

I don’t see how SOA improves performance, have you some references for
this assertion?

Colin

5

SOA and performance are two of the most abused terms in IT, so
definitions
matter a lot. I take the first to mean a set of principles applied to
the
design and development of systems and complex solutions (go to Wikipedia
or
Google define:SOA for a list) and the second as the ability of a system
or a
component of a system to do its work efficiently (more operations in the
same amount of time, the same number of operations in a shorter time).
That
being the case, I have a hard time understanding the original question
because all of these concepts seem to be more or less orthogonal to one
another. Architecture and implementation technology are certainly going
to
have an effect on performance, but they don’t determine performance or
scalability (related term, though not the same, also badly abused) as
much
as how they’re applied which is largely determined by application
complexity
and the skill of the development team.

See http://railslab.newrelic.com/scaling-rails for an introduction to
things
that do matter when designing and testing a Rails application for speed.

I have the feeling that none of the answers you’ve received are really
answering your question though. Could you further specify what you’ve
heard
and what you’re looking to find out?

6

Hey folks,

I allow that I likely mangled the use of the term ‘performance’, but I
think the question stands, because anyone consciously refactoring
their Rails app to accommodate an SOA approach would surely know it:
models now implemented as services would respond to HTTP requests or
messaging services like RabbitMQ.

Before I list the purported benefits as I have read them, let me set
context. A part of my Rails app could possibly succeed as its own app,
while its existence also benefits the rest of the app I have underway.
Shouldn’t I want to develop this independent piece as an autonomous
service while also allowing for its use by the rest of the app?

It is said…

  • organizational efficiency - services are isolated, so development
    teams focus on their assigned service(s) alone
  • robustness - services have their own data stores and modifications
    to them is independent from other services
  • scalability - rather than optimize the common Rails data store to
    meet all cases entailed by use of the app, each service and its
    associated use case entails its own particular database optimization

Lille

7

Lille,

sinatra is WAAAY better than rails for building a web service API - I’ve
built two API’s in sinatra in the past week, one of them took only 1.5h
(this w/ oauth, get/put/post/delete, etc.). Compare this to when I
tried to
build an API in “The Rails Way” , which at the time was ActiveResource
(which has since gone fallow), which took weeks.

If you’re using something like amazon’s S3 or SQS or SimpleDB, then
congrats, you’re doing SOA. My understanding is that the culture inside
Amazon was always very heavily SOA-oriented, and top management frowned
on
efforts that involved reinventing commodity functions like storage or
queueing - and this led to their cloud business.

The S is SOA is Service - if you want to provide a service, then SOA may
be
a good idea. If you want a nice clean separation between API and
everything
above, and if you think your web service API might some day be used by
other
business units, partners, mashups, etc., then sure, you can think of it
as a
service and you’re doing SOA.

AFAIK the only connection between SOA and performance is that you can
focus
on optimizing your service, and if you provide a really good service you
could perhaps have economies of scale - but on the other hand you can
focus
on optimizing any section of code.

m

8

Marc,

Thanks, yes I have perceived the benefit in taking more of a Rack-
based approach to Ruby web service development.

Question: For any of the Ruby webs services you have built, did you
consume it in another of your services or in a Rails app?

Lille