working in the clouds

by K2 on November 19, 2008

Up until recently I’ve hosted all of my hobby/small Rails sites at Textdrive. It was inexpensive, the documentation fairly thorough, and support was responsive. About a month ago, I started putting together another small Rails site. I built it locally and was ready to deploy to my server at TextDrive. However, the server had an old version of RubyGems, and I found out that wouldn’t be upgraded. My plan was being outmoded, and needed to upgrade my plan (aka, spend more) and move my code.

I really wasn’t in the mood to do this, and so I took the opportunity to look into some of the other services getting a lot of press lately: Namely the “managed” cloud services–those apps that use EC2 or other elastic services, but put a nice front end on more easily manage deployments. The following are some first impressions on each of the services I worked with:

Up until recently I’ve hosted all of my hobby/small Rails sites at Textdrive. It was inexpensive, the documentation fairly thorough, and support was responsive. About a month ago, I started putting together another small Rails site. I built it locally and was ready to deploy to my server at TextDrive. However, the server had an old version of RubyGems, and I found out that wouldn’t be upgraded. My plan was being outmoded, and needed to upgrade my plan (aka, spend more) and move my code.

I really wasn’t in the mood to do this, and so I took the opportunity to look into some of the other services getting a lot of press lately: Namely the “managed” cloud services–those apps that use EC2 or other elastic services, but put a nice front end on more easily manage deployments. The following are some first impressions on each of the services I worked with:

buildingsAndCloud.jpg

heroku

I had expirimented with Heroku right after it was first released. Uploading your code to the service seemed to be foolproof. Zip it up and upload. I had read about issues with some gems, but nothing that I ran into. I had one of my first apps up and running very quickly. heroku was differentiating itself with its online code editor. Initially, the editor was interesting, but not all that useful except for the most basic applications. I think most people, including myself, prefer to work locally, commit it to whatever repository you’re using, then upload your code via Capistrano, FTP or whatever.

So, for my new app, I used the same process I had originally: tar up the app and then upload it in heroku control panel. When I did this, I kept getting server timeouts and 413 “Entity Too Large” errors, even though it was a very basic app. A couple other people posted similar items on the heroku Google Groups forum. Looking around the heroku site, it just didn’t seem like there was much activity. The “Recent Posts” on the heroku home page had one from November, two from September and then some from May. My thought was that maybe the service was going away, so I left.

One note on heroku: I didn’t find this/spend the time to find this, until after my upload issues, but you can now install a heroku gem, making it much easier to create apps, with automatic git integration, and more. You can:

sudo gem install heroku
heroku create myapp

This would have been nice to know, and probably wasn’t that hard to find. However, I didn’t find this out from the heroku site itself, but rather from another blog. I would think that heroku should put this right on the “import” area stating the gem is the preferred was to manage deployments.

Aptana Cloud

I’ve been using Aptana for quite a while for Rails development. I know some hardcore rails developers balk at this, but I really do like the Javascript and CSS editors, the list of rake tasks when I can’t remember one, and other niceties like this. I’d long ago turned off Aptana’s home page constantly talking about new features, Jaxer, etc. which I really didn’t care about. I’ve also found the Java interface a bit buggy, and sometimes overly complicated/unintuitive.

About the same time I was frustrated with heroku, I noticed the little “Cloud” button on the top left of the editor. It turns out that Aptana is including easy deployments right from their Studio tool. Very interesting. Will it be as clunky as some of the features as some of the editor features? The answer is no with a big asterisk. Right now, the Aptana Cloud does not support Rails, only PHP. However, Rails is listed as “Coming Soon”.

I did go ahead and deploy a static HTML version of my site, and I do have to say the deployment was easy, the interface intuitive and overall I think it has potential. The deployment has some of its own synchronization logic built in, which is nice and easy for a single developer. I didn’t dig deep enough to see if this uses an existing SCM, and could therefor be effectively be used with teams and those not using Aptana. In the end, the Aptana Cloud is something I’ll be keeping my eye on, especially after Rails is included.

Morph AppSpace

Morph had a big presence at this year’s RailsConf in Portland. With Aptana and Heroku down, I decided to give it a try. I have to say I really like what they have to offer. Getting going was fairly intuitive:

  1. Create a “subscription” (what a subscription is could be described better - it’s really just a virtual server instance if you’re in their free mode or a cluster of servers in paid mode).
  2. Create the database on your subscription. There is a button on your subscription to do this. You don’t have to name it anything special, the deployment script handles this.
  3. Download and update a CAP (Captistrano deployment .rb) file with your SVN or git repository, and a few other configuration items. Note: You need to have Capistrano installed - a simple one line gem install.
  4. Make sure you have your rails instance and all gems local. There is a great article on “Vendor Everything”, which is how I will do all my deployments from now on. Coming from a Java world, the concept of depending on what gems were installed on a host seemed foreign. I like this strategy much better.
  5. Make sure you have commited your code to SVN/git/whatever.
  6. Run the morph_file via Capistrano.

    cap -f morph_deploy.rb morph:deploy.
    

If all goes well, your server will be deployed in about five minutes. If it doesn’t, look at the “log” tab on the control panel for your subscription. I did notice that sometimes there were logs that showed up here, sometimes they did now. I’m not sure if there is a delay, so if there is nothing there, wait a couple minutes and try again.

Morph offers free deployments, with some caveats: The free versions cannot have a custom domain name, you need to use the appname.morphexchange.com domain. You also need to do a deployment every 14 days to show you’re still using the app or it go poof. Morph also just added a provision where you can only have two free subscriptions going at a time. You can buy instances starting at about $1 USD/day. Morph also offers full “clouds” that include load balancers, dedicated DB instances, etc, for larger scale projects. These begin around $1500 USD/month.

All in all, I’m very happy with Morph and opted for a paid subscription for one of my smaller sites. I will also be looking at it very closely for larger scale deployments in the near future.

5 Comments »

  1. Alain Yap, Morph Labs Said,

    November 28, 2008 @ 11:09 am

    Hello!

    We’ll be looking at our ’server’ concerns as you’ve pointed out and find out more about why this occasionally happens.

    Thanks for the valuable feedback. Nice to hear that you’re on the Morph AppSpace and is happy with it. So are we!

    Happy Thanksgiving!

    Best.
    alain

  2. Mark Said,

    November 28, 2008 @ 10:02 pm

    Hi,

    Thanks for your valuable feedback on our service. If you have time, I’d like to hear more about your thoughts on Morph AppSpace and AppCloud. Please do drop me a line when you find the time.

    Regards,

    Mark

  3. Guy Naor Said,

    November 29, 2008 @ 12:07 pm

    Thanks for the info about Morph! A few comments to clarify things and make your life easier:

    1. There is a wizard to generate the cap deploy file based on your source control and some other parameters. Using it generates a ready to run cap file, eliminating the need to update it locally.

    2. Though we recommend vendoring everything, and with Rails 2.1 and 2.2 this is actually very easy, we do provide a wide selection of pre-installed gems, and add more based on user requests.

    3. Logs take up to a few minutes to appear in the UI as it is managed by a background process controlled with a queue of waiting deploys. That’s why sometimes it takes a minute and sometimes a bit more.

    Bye,

    Guy.

  4. K2 Said,

    November 29, 2008 @ 12:18 pm

    So, I think the morph folks all got the Google Alert on this post at the same time!

    On Guy’s comments:
    1. Cap Wizard: Yes, I did see the wizard. I preferred to see what was actually going on in deploy file, so I edited manually. In the future the wizard is probably the fastest way to go.
    2. Vendoring Everything: I didn’t see where the available gems were listed, and the rails from PDF from morph didn’t mention any as far as I know. Regardless, I like the gem/unpack or vendor everything approach anyway.
    3. Log Issues: Thanks for the clarification on the logs. A note stating this on the log tab of the console would probably be helpful, because I wasn’t sure what happened the first time around.

  5. Ajit Singh Said,

    October 29, 2009 @ 10:42 am

    Hi

    can you please update this article with your thoughts on Aptana cloud now.. as they are offering Rails hosting now.

    Regards

    Ajit

Leave a Comment