The prediction of Ruby development in 2010:

By September of 2010, the new RoR sweet spot will emerge.

It will combine Amazon EC2 Instances overlayed by an optimized Ruby 1.9.x and Rails 3.x stack from a Rails hosting service, such Engine Yard or Heroku or RightScale. In addition to the usual MySQL and PostgreSQL, they will offer at least one distributed database. The one to look out for is called Cassandra. It provides an idea of “Eventual Consistency”. Never heard of it? No worries, you’ll hear all about it within six months. The good folks at Facebook open-sourced a beta version in August of 2008. It appears that Cassandra may be the best distributed database for typical RoR applications.

Cassandra is great for Rails apps because, unlike car or plane control systems, most of our database-driven apps are not hard-core realtime. This helps Cassandra break the ACID paradigm and still survive. Each one of Cassandra’s DB servers owns only a portion of a database. As result, Cassandra cannot mimic RDBMS by telling the database to replicate at write time. Instead, replication is relegated to a background task on each node of a cluster.

The good news is the database regains consistency shortly after. This works well when you don’t need to show the customer all transactions. Even better – result of customer’s action is visible to that customer immediately.

The database is not Consistent and therefore not ACID. It is not a good database for bank transactions.  It is a good database for many other apps. Amazing.

For this post, we praised the database enough. The other parts of the stack are not shabby either. We’ll look at them in the next post.

Until next time,
Bloggers @ Sphere