A few nights ago, I went to a talk about using Ruby on Rails (RoR) on Google’s AppEngine. Python was the first language supported by AppEngine. Java is the second. Using RoR on AppEngine requires compiling Ruby to Java bytecode using the JRuby compiler and runtime enviroment. RoR applications on AppEngine gain the security benefits of running in a JVM, but this also imposes restrictions on what sort of packages the application can use.
Moving an existing RoR application to AppEngine requires remapping ActiveRecord data from a SQL database to Google’s DataMapper machinery. This store is basically a hash-map that may be distributed over multiple machines — transparently. Joins are not possible with this representation. The speaker made the claim that for data that suits this type of store, queries require time proportional only to the result set size.
To get your code and data up to the server you need to compile it (using JRuby) and upload it (as JAR files). Managing your static file content and Ruby gems sounded tricky because there isn’t a proper file manager or shell interface. And it isn’t possible to use gems that have binary components (like RMagick – the Ruby binding for the ImageMagick package).
Performance tuning seemed difficult. Threading is not supported to interleave transactions. Rather, new machine instances are spawned based on load; a new instance takes about 30 seconds to get up and running.
It’s an intriguing offer: use Google’s machinery to host applications in the cloud that scale transparently and are free for about up to 500M pages per month. For me, it seems there are too many layers between the application and the hardware, since you never really get a host: at any given time your application may be running on any number of hosts — anywhere. It will be interesting to watch this type of cloud computing fight it out in the marketplace with cheap managed virtual hosts and other approaches.