Should I deploy my Ruby on Rails application on Heroku

Question

A little about myself. I am 24 years old, I graduated from NC State with a Master's in Analytics last year. Statistics, mathematics, that kind of thing. I don't have a strong programming background, which is pretty important for my question. If I say anything that doesn't make any sense, that is why. Ever since graduation, I have been working full time on a Rails app with a few other people. My programming experience is mainly Ruby on Rails (1.2 years.) I know R, SAS (statistical languages, not helpful for this question.)

Obviously, that means it has been over a year in development, and we aren't done yet. The main developer is an excellent programmer, just that he has a full time job already, and does this app in his spare time. Due to him not having enough time recently, I have been given practically full responsibility for the app.

We have it deployed on Slicehost right now. The app is at a point where we don't need to program anything else (unless we think of more features.) The reason I am asking if we should migrate to Heroku is that it seems to me that Heroku is a simple platform to which to deploy. Slicehost seems too complicated for me. The other developer dealt with it, and not me. I looked at how to deploy the app on Heroku, and it looks like I would be able to do it. We need our app to scale if it needs to, which Heroku offers. As far as money, I would start it at the minimum (free) and see how it goes. I can pay for additional features if I need to.

We are using Redmine for project management and repository (not git, which I think we need to use on Heroku.) Is git similar to Redmine? Is it easy to use?

Right now, on Slicehost, we have 4 daemons (constantly running processes.) We have 8 delayed_job workers. I know the command line to start the daemons and delayed_job workers. Would these work on Heroku?

I am wondering if I can still use RAILS_ENV=production script/console with Heroku.

The user interface is a javascript file. In development mode, if I do script/server in a terminal, and go to http://localhost:3000 in a browser, I can see it. Would Heroku load this page the way I want?

We have a working website for the app, with our own domain name. I don't really know what DNS is, so I probably wouldn't be able to link the Heroku app to it, unless there is an easy way. I think Heroku links it to appname.heroku.com as a default.

Based on my programming experience, would Heroku be easy enough for me to use, should I find another job, or should I commit seppuku?

Answer 1

Yes, you should definitely deploy your application in heroku. To do this, this is what you will need to do:

1. Make sure you have git installed in your computer
2. Create a heroku account here
3. Install the heroku gem and do the rest as mentioned in this page
4. Track your application with git, and create your heroku application as shown here
5. After you do this, heroku will provide you with a URL for your application, such as http://blah-bleep-123.heroku.com. Now, the next step would be to associate your domain to this heroku URL.
6. Configure your domain DNS Server as shown in this page. Mind you, after you change your DNS, it might take upto 48 hours for it to work. You can change your domain DNS by logging into the site where you bought your domain, for e.g. godaddy.com, hostingdude.com, etc.

7. Add this code to your ApplicationController. You can follow this from this page as well

   class ApplicationController
     before_filter :ensure_domain
   
     APP_DOMAIN = 'www.mydomain.com'
   
     def ensure_domain
       if request.env['HTTP_HOST'] != APP_DOMAIN
         # HTTP 301 is a "permanent" redirect
         redirect_to "http://#{APP_DOMAIN}", :status => 301
       end
     end
   end
   

8. Make sure you migrate all your database in heroku, by doing heroku rake db:migrate
9. After you have completed all these steps, you should be good. Check out your domain URL, everything should work pretty :).
10. If you see any errors in your page, you can view the log by heroku logs
11. You can access console as heroku console

With features as these, heroku is very convenient to work with.

Please let me know if you need more help.

Answer 2

It seems to me like you should seriously consider Heroku. I have used it for weekend projects and we use it at work as well, quite successfully. Deployment is a breeze, you don't have to worry about setup (for the most part) and system administration. It's super easy to add modules and "pay as you grow".

As for your needs, you could (I believe) run your redmine on Heroku itself, being a rails app. The only thing is that you mention you use Redmine as "repository" and I'm not sure I understand what you mean, since Redmine is not a version control system. Redmine has integration points for various VCS (SVN, git, Mercurial, CVS, and others). Yes, Heroku uses git and that is what you would need to use in order to push code to the server. If you're familiar with Mercurial, it's pretty similar.

For delayed jobs, Heroku offers free cron jobs that run once a day and hourly ones for a fee (see cron add-on). There is also a delayed job plugin (see this) but I don't have any experience with it.

You should be able to access the Rails console (see heroku docs). Just run 'heroku console' and voila, you're there.

If your app works by running script/server, it should work out of the box in heroku too.

As for the DNS, getting it to work with your custom domain is not hard. Out of the box, you can access your app with appname.heroku.com, to set up your custom domain check heroku docs here, but basically you have to add the custom domain add-on (free unless you want subdomains), configure heroku to respond to your domain's requests (couple of simple commands) and set your DNS provider to point to Heroku (there's even a short video in the docs on how to do this with GoDaddy).

The only drawback I've seen with Heroku, and it's not a huge one, is that if your app does not receive any traffic for an extended period of time, the instances kind of "go to sleep", making the next request to arrive somewhat slow (sometimes even timing out), but once the instance is awake, everything is good to go.

All in all, I think Heroku is a great way to take a ton of the burden off of you as a dev and making a lot of things really easy to implement without having to go into the nitty gritty of setting up a server. The downside: once you start growing, it can become somewhat expensive, but hey, if you're growing it probably means you have the cash now to hire someone that can take care of the nitty-gritty.

You might also want to take a look at this blog post which compares Slicehost and Heroku

Best of lucks

Answer 3

YES, go for it.

If you've managed thus far on the strength of your 'programming experience' then you'll be fine. Have some confidence and ship something! To quote Paul Graham:

The reason to launch fast is not so much that it's critical to get your product to market early, but that you haven't really started working on it till you've launched. Launching teaches you what you should have been building. Till you know that you're wasting your time. So the main value of whatever you launch with is as a pretext for engaging users.

The functionality you outline is easily replicated and well documented and it's free to start with. What else could you ask for?

Answer 4

YES, go for it.

Its good deployment environment any its fast and easy scale out and scale in feature. even you can use for your testing or demo usage its provide you free account usage of 1 dynos per app.

List of add-on tools available you can add as per your requirement.

Answer 5

If you have the free time, you might as well sign up for a free account and give it a shot.

HOWEVER, this is going to come with some pretty severe headaches.

Version control will be one, since heroku uses git, but another one that no one's mentioned yet is that your 12 processes ("dynos" in heroku speak) would cost you $35 * 11 = $385 per month! You can set up an hourly cron for $3/month that will flush your delayed_job queue (instead of having workers running at all times), but is that going to be adequate? (If you're running 8 workers, I'm guessing not). This may or may not require some code changes.

Once you get it set up, deployment and admin is really easy (nonexistent), but it'll cost you if you start needing new features.