Morph, Ruby on Rails, and Amazon Web Services

The Morph Application Platform, the first Platform-as-a-Service for Ruby on Rails, leverages Amazon Web Services for the deployment and delivery of Ruby on Rails applications. The technology behind the Morph Application Platform allows us to provide developers with an elastically scalable platform to deploy their Ruby on Rails applications to while keeping expense to a minimum. While the concept of a Platform-as-a-Service (PaaS) is something we've covered before, the latter part about Amazon often brings up a lot of questions.

Where the confusion often occurs has to do with how the Morph Application Platform interacts with Amazon Web Services and more specifically, how developers deploying to the MAP must interact with AWS. To be perfectly frank, we specifically reference Amazon because it is a well-known brand that people recognize. From a developer standpoint, however, you could deploy to the Morph Application Platform and never know that Amazon was even in the mix..

Essentially, in the truest sense of the Platform-as-a-Service philosophy, the Morph Application Platform abstracts the underlying architecture; in this case the Amazon EC2 architecture. Think of the Morph Application Platform as a "Virtualized Application Environment" where our abstraction layer is the next generation of virtualization at the infrastructure level. the MAP uses commodity software and intellectual property to build a completely seamless layer of services that product enterprise class deployment, delivery and management to applications.

What this means is that when you deploy your application to the Morph Application Platform, you do not have to make any changes to your application and you never actually work directly with EC2. In fact, you don't have to work with any of the Amazon Web Services, though you can certainly leverage S3 or SQS directly for centralized object storage and queuing respectively. The key here is that you do not have to interact with AWS if you don?t want to.

There are a number of reasons for this abstraction of the underlying technology. Other than keeping the details of what is happening under the hood away from the developer so they can focus on the core product, there is another big reason for this. Morph is not here to be a front-end for Amazon. Since we completely abstract the underlying infrastructure, we can add new grids as they come online and even spread your application across grids. We get to leverage multiple clouds for the redundancy benefits and the developer doesn't have to make any changes.

It seems a lot of the confusion about how Morph leverages EC2 or how you as a developer leveraging the Morph Application Platform works with EC2 is due to the plethora of projects, talks, and blog posts about using Ruby on Rails and EC2. Most of the articles out there talk about using Rails as a front end for deploying EC2 images, something that is completely different that running a RoR application on an EC2 instance. Here are some of the resources from around the web on using Ruby on Rails and EC2:

Libraries and Projects

• http://amazon-ec2.rubyforge.org/
• http://ec2onrails.rubyforge.org/
• http://code.google.com/p/scalr/
• http://www.elasticrails.com/

Talks and Presentations

• http://mtnwestrubyconf2008.confreaks.com/05younger.html
• http://www.slideshare.net/johnward/amazon-ec2-rails/
• http://thinedgeofthewedge.blogspot.com/2007/06/amazon-ec2-rails.html
• http://blog.marcchung.com/2008/02/ec2-at-phoenix.html

Blog posts and Articles

• http://railspikes.com/2007/4/5/rails-on-ec2
• http://pauldowman.com/projects/ruby-on-rails-ec2/
• http://www.rubyonrailscamp.com/AWS+Console
• http://niblets.wordpress.com/2007/02/12/capistrano-ec2-sitting-in-a-tree-k-i-s-s-i-n-g/
• http://www.igvita.com/2007/05/15/distributed-ruby-workers-on-ec2/
  

As you can see, even with the continuous improvement of the EC2 product, the conclusion is definitely this: It is a lot of work to leverage EC2 as a server environment for your Ruby on Rails application.

Just to put this all into perspective, EC2 has historically (since its launch just a few years ago) been used when computing power is needed on-demand. It is relatively trivial to "spin-up" instances to handle asynchronous processing, but to leverage EC2 for scalable web applications is a very different proposition. Add to that redundancy, load-balancing, databases, filesystem issues, etc. and you can see the value of a PaaS such as Morph Application Platform that leverages AWS while abstracting the underlying difficulties from the developer is necessary.

There are commercial and open source projects that provide you with a pre-configured image to place on EC2 (Linux-based system with Ruby on Rails) to run your Rails applications on the ?cloud?. Unfortunately those are still not abstracted enough from EC2 for the average Ruby on Rails developer looking for a simple deployment environment. It is our MAP technology, the "Virtualized Application Environment", that is the abstraction layer that allows developers to focus on their core product and not worry about the underlying systems and to keep costs down far below what you would pay to deploy a dedicated EC2 instance just to host your small Rails application.