Epseelon

Why I switched back from Heroku to CloudBees

I used to have several grails applications deployed on CloudBees. I liked the fact that they were Java all along, I liked the smooth integration between Jenkins CI and the deployment environment. I really liked the fact that you could hide an application behind a username and password during testing. I just hated their design (seriously guys, hire a good designer) and I was not thrilled by their catalog of third-party services. So when Heroku announced that they supported Java applications, and then Grails applications, it was not long before I migrated all my apps over to their servers.

But more recently, I’ve had issues with a more plugin-rich application. And tonight, after several weeks of fighting, I migrated this app to CloudBees for one general reason: Heroku was really designed with RoR in mind, and even though they made a new stack for java apps, the old rules still apply:

  • if an application takes more than 60 seconds to boot, it is crashed. There is no way to adjust this timeout, and we all know that it can be pretty common for a java app to take a little more than that.
  • another consequence of this slow boot intolerance is that an application is automatically put in sleep mode after several minutes of not being used. Consequence: when someone comes to the site after such a period, say, in the morning, the app is rebooted out of sleep mode… and sometimes it crashes again. Terrible for availability. And apparently, even if you pay, there is no way to prevent that sleep behavior and to keep your app alive all the time. Actually to be fair, there is a way to disable idling: once you scale up to 2 dynos, idling is disabled.
  • since your app can be sleeping, implementing long-running background processes is very complicated too. You have to use their worker processes, but there is no documentation on how to do that in a java application, let alone in a grails app.
  • last but not least, even though I tried to limit the amount of memory of my app, it kept going over 512MB, which is the absolute limit. Once again no way to change that. It doesn’t crash my app, but it clutters my log with plenty of annoying warning messages.

That plus the fact that they refused to answer my last support request about memory consumption and marked it as solved when it got hard. The fact that they don’t have an easy continuous integration feature was not a deal breaker, but it adds to the rest.

Now I don’t know if CloudBees will be better on all these points, but it looks good on paper. Unfortunately, we java devs don’t have a lot of choice when it comes to cloud deployment. CloudFoundry is way too low-level, AppFog is still in private beta, and Amazon Elastic Beanstalk is awful for deployment (40MB take a long time to upload). What other options do we have that I’ve never heard of?

 

Sebastien

,

17 responses to “Why I switched back from Heroku to CloudBees”

  1. Hey, Sebastian, consider trying our Java PaaS: http://jelastic.com – designed specifically for Java, has automated vertical scaling (get more memory & CPU on the fly), no code changes required and you get full control over the app servers. Would love to have you with us! 🙂

    Reply

  2. You could look at OpenShift (http://openshift.redhat.com). We use JBoss as our app server and we also allow you to use Jenkins. We are pretty active in the #openshift channel on freenode. Finally the whole stack is opensourced as well so there is no lockin. Please be aware that we are still in developer preview. Bad part means not quite ready for production but soon, good part means we are actively working on improving the experience so feedback is taken very seriously.

    Reply

  3. Sebastian,

    I can’t find any record of the support request you mention. As for your other issues:

    * memory is something we are thinking about out
    * here’s a doc on java worker processes: https://devcenter.heroku.com/articles/run-non-web-java-processes-on-heroku
    * you can easily avoid idling of dynos. Just scale your app to 2 or more dynos and it will never idle out. Also worker dynos never idle out.

    I am sending you an email separately to get your help locating the support request you mention.

    Regards,
    Jesper
    Product, Heroku

    Reply

  6. Did you try cloundfoundry? At started on it for a grails application. The plugin makes the deployment very easy.

    Reply

    • Sadly I must agree with you that cloudbees is the only option to go, although openshift looks good, it’s only offering OpenJDK as runtime environment and installing your own java app can get difficult. Heroku has a 512MB limit and stops the application as soon as it exceeds this capacity. Jelastic has no free plan, you have to pay different amounts, depending on what hoster you choose. Although cloudbees says that it doesn’t allow more than 128MB of RAM, it’s no priblem to have an app running at 256MB. And with the cloudbees plugin you don’t need to upload a whole WAR file at a time.

      Reply

    • We use Cloudbees pretty extensively for Jenkins and as a Maven repo. We don’t host there right now. My biggest complaints are the UI still sucks and the storage limits for paid plans are crazy low considering the expense we pay.

      Reply

Leave a Reply

%d bloggers like this: