Links

 

SimpleWorker: run and schedule jobs in the cloud

SimpleWorker is an easy way to run tasks in your application in the cloud. It's perfect for using as a worker queue to run background jobs for your app. You can also use it as a Ruby Compute Cloud for running large jobs or sets of parallel jobs in the cloud.

It's simple, transparent, and ready to go as soon as you sign up. Here's how it works. You create worker classes in your code and then you queue them up in your app to run immediately or schedule them to run later. The jobs get passed to SimpleWorker to run in the cloud. It's that simple.

A few of the key features and core benefits include:

Runs background jobs in the cloud
Easy to use, painless to setup, ready to go from the start
Flexible scheduling - one-time in the future, recurring schedule, very configurable
Massively scalable and parallel - queue up and run as many jobs as you want
Extremely cost effective - $0.05 per hour billed by the second so you really only pay for what you use. If you only use 1 minute per hour you only pay $0.0008 per hour.

5 hours are free.

http://www.simpleworker.com/

Filed under  //   aws   cloud   queue   ruby   worker  
Posted March 3, 2011 by email 
 

Nanite: self assembling fabric of ruby daemons

Nanite is a new way of thinking about building cloud ready web applications. Having a scalable message queueing back-end with all the discovery and dynamic load based dispatch that Nanite has is a very scalable way to construct web application back-ends.

A Nanite system has two types of components. There are nanite agents, these are the daemons where you implement your code functionality as actors. And then there are mappers.

Mappers are the control nodes of the system. There can be any number of mappers, these typically run inside of your merb or rails app running on the thin webserver (eventmachine is needed) but you can also run command line mappers from the shell.

Each Nanite agent sends a ping to the mapper exchange every @ping_time seconds. All of the mappers are subscribed to this exchange and they all get a copy of the ping with your status update. If the mappers do not get a ping from a certain agent within a timeout @ping_time the mappers will remove that agent from any dispatch. When the agent comes back online or gets less busy it will re-advertise itself to the mapper exchange therefore adding itself back to the dispatch. This makes for a very nice self-healing cluster of worker processes and a cluster of front-end mapper processes.

In your Nanites you can have any number of actor classes. These actors are like controllers in Rails or Merb and this is where you implement your own custom functionality.


https://github.com/ezmobius/nanite

Filed under  //   actor   amqp   cloud   distributed   rabbitmq   ruby   system  
Posted February 8, 2011 by email