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?
17 responses to “Why I switched back from Heroku to CloudBees”
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! 🙂
I’m giving it a try right now. Too bad all your communication is in German.
You must have signed up with our German partner dogado! We have partners in USA and UK – English speaking. When you go to http://jelastic.com select an account with one of those providers and all correspondence will be in English 🙂
All documentation is also in English at http://jelastic.com/docs
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.
I’m giving it a try right now.
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
[…] Why I switched back from Heroku to CloudBees […]
[…] Why I switched back from Heroku to CloudBees […]
Did you try cloundfoundry? At started on it for a grails application. The plugin makes the deployment very easy.
Uhurucloud. Pretty beta, won’t be for long, but developing rapidly. Nice community. Cloundfoundry on steroids (Foundry has a vmc CLI, Uhuru has vmcu.
Read my blog post here – http://blog.skuda.net/post/31462863488/uhurucloud
Hey Sébastien, I’m making this same decision at the moment. How have things gone with CloudBees? Still glad you switched back?
Still very happy. A little expensive but the simplicity is really awesome.
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.
Have you seen the new interface of cloudbees? It seems like they took you advice of hiring a designer! 🙂
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.
[…] Why I switched back from Heroku to CloudBees […]
Azure Web Sites now supports Java! Maybe you can give that a spin…