Here at Square Talent we’ve moved to running all our Radiant sites off Heroku (we’re still using slicehost to run watchy), that’s how Dad did it, that’s how America does it, and it’s worked out pretty well so far.
I’d like to share my experience with this over the past 3+ months, and hopefully help others looking to go down this path.
Heroku Goes to Sleep
We’re not all running sites that get 200 hits a minute, let alone an hour, some won’t reach those results in a month. In fact their most recurrent visitor during the quiet period is going to be themselves, and they’re going to notice everything.
So when the app takes 6 seconds to spin up, they’re going to be on the phone complaining that it’s broken.
I’ve picked through the acceptable user agreement and not seen anything to say we shouldn’t do this.
Check out watchy and chuck it in a cron job.
Heroku is read only
This will trip out new players, the general method of using a /public/assets folder is out of the question, with write access only granted to a temp directory.
So a cms that needs to store its assets will need to use a remote service, for that we choose Amazon’s s3. Until recently we were running on EU servers, which was starting to cause headaches when paperclip moved to aws/s3.
Heroku runs on US EC2
Deal with it, come to terms with it, and don’t go against the grain. The first thing we did was run off of EU, we’re in Australia so this was going to be faster right? I could never tell so I didn’t really think about it.
Then amazon came out with Sinapore s3 and I instantly moved two clients over to it right before launch.
Mistaaaaaaaaake….
This prompted a week long investigation into the app hitting a 30 second time-out when they were uploading pictures. Then trying javascript hooks to reset the page, flash based uploads and cutting back on multiple styles.
All for a speed improvement which was completely unnoticeable as the user had to hit Amazon’s US servers just to make the request to Singapore.
Heroku will get expensive
They’re not around to provide a free ride, one of our options for avoiding app time-outs was to go to background workers. Firstly this would be a big pain in the ass as we’d need to rewrite a heap of scripts and interfaces, secondly it would cost either $37 a month, or require more code to call workers on and off as we required them.
Also your database is going to start costing you as you grow beyond 15meg, so make sure you’re storing data smartly.
Taps and Radiant is love
I wrote earlier about how taps can help you manage a local or alternative development database and a live version. It’s been working really well for a whole host of projects, and this has opened up an opportunity for us to move all data (stylesheets and javascripts) straight into the database.
This will have great ramifications in the delivery model we use for the entire business, more to come on that over the next few months.
Heroku and Radiant Caching
Radiant will override the cache headers sent by heroku, so if you’re making changes to a system on production you’ll be waiting for 5 minutes for the those changes to be reflected.
This gets really annoying really quickly, and we are working on a fix for this, hoping that hooking the cache headers after Heroku gets a chance will sort this out for us.
Other things we noticed
-
Singapore redirects your cname hosts to some strange string okay, it’s not doing that anymore.
- Processing file properties (such as changing permissions is painfully slow on Singapore.
- Again paperclip (well aws/s3) doesn’t play nice with Singapore and we needed to introduce a few monkey patches to get it working.