can anyone share the ingredients of a Ruby SOA deployment?

[Lille]

Hi,

I'd like to work exercise my understanding of the concepts of the book
in a VPS sandbox environment. Can anyone recommend, from experience,
the minimum ingredients for such an environment? Any references
appreciated...

Thanks,

Lille

[Sidu Ponnappa]

Hi Lille,

I'm not sure if I'm correctly answering your question, but maybe our
talk from Rubyconf is relavent?
http://blog.c42.in/our-rubyconf-xi-talk-on-rails-services

Thanks,
Sidu.
http://c42.in
http://rubymonk.com

> --
> You received this message because you are subscribed to the Google Groups "Service Oriented Design With Ruby" group.
> To post to this group, send email to service-oriented...@googlegroups.com.
> To unsubscribe from this group, send email to service-oriented-desig...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/service-oriented-design-with-ruby?hl=en.
>

[Lille]

On Feb 4, 2:48 am, Sidu Ponnappa <ckponna...@gmail.com> wrote:

> I'm not sure if I'm correctly answering your question, but maybe our
> talk from Rubyconf is relavent?http://blog.c42.in/our-rubyconf-xi-talk-on-rails-services

> On 4 February 2012 05:46, Lille <lille.pengu...@gmail.com> wrote:

> > I'd like to work exercise my understanding of the concepts of the book
> > in a VPS sandbox environment.

Thanks, Sidu, your talk was excellent -- refreshingly lucid for a tech
talk -- and always close to motivations addressed in Paul's book. Yet,
it is more high level than what I am after, here (to follow a theme of
your talk, I want to know how the walled (firewalled?) garden is
implemented.)

Let me rephrase my request:

Imagine there was an appendix to Paul's book titled 'how to set up
your first ruby SOA web service (in the cloud)'. I'm wondering what
such an appendix would instruct the reader to do.

Alternatively, where are there any references to Ruby SOA stacks that
I can imitate for experimentation's sake?

Lille

[Jason Dixon]

On Sat, Feb 04, 2012 at 07:03:04AM -0800, Lille wrote:
>
> Let me rephrase my request:
>
> Imagine there was an appendix to Paul's book titled 'how to set up
> your first ruby SOA web service (in the cloud)'. I'm wondering what
> such an appendix would instruct the reader to do.

I think one of the most effective ways to learn this is to try it
yourself with a service like Heroku(*). Use the Cedar stack with its
Foreman-based web/worker model, integrate some 3rd party addon services
(almost all of them have developer/free offerings) and build up from
there. It's a near-perfect microcosm of what you'd experience building
up a large SOA from scratch.

http://devcenter.heroku.com/articles/cedar
http://devcenter.heroku.com/articles/ruby
http://devcenter.heroku.com/articles/procfile

* I work for Heroku, so I'm biased. But it really is a great way to play
around with a lot of the concepts that Paul imparts in his book.

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/

[Lille]

> > Let me rephrase my request:
>
> > Imagine there was an appendix to Paul's book titled 'how to set up
> > your first ruby SOA web service (in the cloud)'. I'm wondering what
> > such an appendix would instruct the reader to do.
>
> I think one of the most effective ways to learn this is to try it
> yourself with a service like Heroku(*). Use the Cedar stack with its
> Foreman-based web/worker model, integrate some 3rd party addon services
> (almost all of them have developer/free offerings) and build up from
> there. It's a near-perfect microcosm of what you'd experience building
> up a large SOA from scratch.

Jason, as it happens I am at the 'Heroku stage' right now. I have
posted to the Heroku group along these lines, here:
http://groups.google.com/group/heroku/browse_thread/thread/58dcfe75902a35a3.

Your references did not help me to get to the SOA stage on Heroku. May
I invite your to carry on a brief exchange on the matter from the
discussion thread linked, above? I can then link that discussion to
this one as the 'Heroku-based approach'.

Lille

[Jason Dixon]

Subscribed and replied.

[Paul Dix]

Hey Lille,
The best way to jump in is to have a motivating example. Some sort of
project that you can build out that will use services. In my book I
had the feed aggregator example because it has a large piece of
functionality that makes sense to be split out as a service: pulling
in feeds.

The trick is to pick the right type of project. If you're building a
CMS, it doesn't really make too much sense to split it out into
services. I can think of one thing (full text search), but that isn't
very interesting since all you do there is start up an instance of
Solr and use one of the many ActiveRecord plugins. However, that is
another example of a partial service based design.

I know that's not really specific, but if you can come up with an
example project I'd be happy to talk about how it might be split into
services that you can try building.

Best,
Paul

[Joe Roberts (zefer)]

Hi Lille.

I have a SOA API platform on Heroku. Each service has 2 separate
Heroku apps, production and staging. Since Heroku allows you to run a
single dyno for free, it costs nothing to run until you scale up. I
scaled my production services up as soon as they went into production.

You could potentially mount multiple services in a single Rack app, or
use Sinatra's modular app design to have multiple services per Heroku
app, but I prefer the flexibility you get from deploying them as
independent services; I believe this gives you the greater flexibility
in the long run.

As an additional, optional step. I have HAproxy running on EC2 which
provides a single URL endpoint to my API, directing the requests to
the appropriate service on Heroku based on the url path (e.g. /api/v1/
something -> something-service.herokuapp.com). You could also use
Nginx instead of HAproxy. Paul kindly suggested this HAProxy solution
response to a question of mine on this group. It works very well, I
have it configured and automated using Chef.

I hope that is of some use?! Good luck.

Joe

On Feb 4, 3:29 pm, Lille <lille.pengu...@gmail.com> wrote:
> > > Let me rephrase my request:
>
> > > Imagine there was an appendix to Paul's book titled 'how to set up
> > > your first ruby SOA web service (in the cloud)'. I'm wondering what
> > > such an appendix would instruct the reader to do.
>
> > I think one of the most effective ways to learn this is to try it
> > yourself with a service like Heroku(*). Use the Cedar stack with its
> > Foreman-based web/worker model, integrate some 3rd party addon services
> > (almost all of them have developer/free offerings) and build up from
> > there. It's a near-perfect microcosm of what you'd experience building
> > up a large SOA from scratch.
>
> Jason, as it happens I am at the 'Heroku stage' right now. I have

> posted to the Heroku group along these lines, here:http://groups.google.com/group/heroku/browse_thread/thread/58dcfe7590....

[Lille]

@Paul - I think my design intention could be well served by the SOA
approach. First, the business logic is separable and independent,
though the whole will certainly be enriched if the pieces can
communicate. Next, the components vary in their persistence strategies
-- some are read-from, some are often write-to -- which suggests
separation will allow for better tuning of the backend store. Finally,
it feels like the smaller any web app can be and still do its job, the
cheaper it will be to run in production, at least due to the smaller
memory footprint. Anyway, the bottom-line is right now I've completed
one component and have the choice of adding the subsequent components
to the first or doing them in an SOA architecture -- so it does feel
like I'm in the right place.

(@Jason - the Heroku google group has yet to show your post reply to
my thread, http://groups.google.com/group/heroku/browse_thread/thread/58dcfe75902a35a3,
requesting comment on possible uses of Heroku for Ruby SOA.)

@Joe - Great, your approach seems like a good start. Two questions: 1)
so I get high-level joins between services (like Paul described in his
book) and 2) have you considered any other means of communication
between the svcs, e.g., messaging with the any of the services they
provide for that, which lately includes RabbitMQ

Thanks to everyone for their kind attention. I think if I can get
HAProxy up and running, then I have a shot at Joe's approach.

Lille

[Jason Dixon]

On Wed, Feb 08, 2012 at 05:18:39AM -0800, Lille wrote:
>
> (@Jason - the Heroku google group has yet to show your post reply to
> my thread, http://groups.google.com/group/heroku/browse_thread/thread/58dcfe75902a35a3,
> requesting comment on possible uses of Heroku for Ruby SOA.)

Dunno what happened there. I posted a reply via the Google Groups
interface. Oh well, sounds like you've found a solution. :)

[Joe Roberts (zefer)]

Hi Lille.

> Two questions: 1) so I get high-level joins between services (like Paul described in his book)

I have written a client gem, which performs the joins between services
using Typhoeus. I dabbled with using Event Machine but grew to really
like Typhoeus. For example, this app http://artistic.ly/ which runs on
the platform, when the app requests artworks, it requests the
associated artists in a parallel request, very much like Paul
describes in his book. Although, I have now merged the Artists into
the Artworks service since these joins are so common, so I've probably
given a bad example!

> and 2) have you considered any other means of communication

I'm not using RabbitMQ. I'm trying to keep things as simple as
possible, for now, but will be considering it to help us handle large
volumes of writes, by making them asynchronous and queuing the jobs
with RabbitMQ. It's not something I have explored yet as the need
hasn't arisen. I am using Resque to handle background jobs. This has
been a great as it allows jobs to be categorised into different
queues, so different jobs can be processed by different servers, and
any service can queue them up. On Heroku, it's as simple as defining
workers in your Procfile. Your worker can be assigned to process
specific queues, or process everything. It's therefore very easy to
scale up processing of different job queues and it would be no problem
to set up a cluster of servers elsewhere dedicated to processing
specific job queues.

Joe

On Feb 8, 1:18 pm, Lille <lille.pengu...@gmail.com> wrote:
> @Paul - I think my design intention could be well served by the SOA
> approach. First, the business logic is separable and independent,
> though the whole will certainly be enriched if the pieces can
> communicate. Next, the components vary in their persistence strategies
> -- some are read-from, some are often write-to -- which suggests
> separation will allow for better tuning of the backend store. Finally,
> it feels like the smaller any web app can be and still do its job, the
> cheaper it will be to run in production, at least due to the smaller
> memory footprint. Anyway, the bottom-line is right now I've completed
> one component and have the choice of adding the subsequent components
> to the first or doing them in an SOA architecture -- so it does feel
> like I'm in the right place.
>
> (@Jason - the Heroku google group has yet to show your post reply to

> my thread,http://groups.google.com/group/heroku/browse_thread/thread/58dcfe7590...,