Heroku versus Cloud Foundry from an Educator’s Perspective
There are several useful comparisons between Heroku and Cloud Foundry, including this one and that one. I am going to add a brief educator’s perspective.
Why APaaS in the first place? To have a common reference platform for students to deploy to from day one. This eliminates the common last-minute deployment problems.
My specific requirement is to support the technology stacks I have chosen for pedagogical reasons for my web application and web services courses. (In both courses, we pay considerable attention to architecture.)
- Scala
- Play framework for web apps
- spray for RESTful web services
As a platform, Cloud Foundry is open-source, while Heroku is closed-source. Fair enough. But what are the relevant differences from my perspective?
- With Heroku, your application needs to have a main class as its entry point. You structure your application using Foreman and push the source to the cloud using git. Building, staging, and deployment then take place again in the cloud. If these steps work on your local machine using, say, Maven or sbt, they are very likely to work the same way on Heroku.
- With Cloud Foundry, your application must be packaged as a war to run on Tomcat 6, in the case of Java or Scala. The build process takes places on the local machine, you push a war to the cloud, and this hard-coded server staging logic is invoked. The problem is that you are stuck with the default blocking Java connector! Because spray requires the non-blocking (async) connector, this means that you cannot deploy spray to CloudFoundry.com for now. If you know a workaround, please let me know!
- Both have various useful add-ons, such as relational and NoSQL databases, message queues, etc.
- Heroku has a free tier, while Cloud Foundry has a free trial and it’s final pricing structure has not been announced yet.
For these reasons, I ended up choosing Heroku for this spring semester. I’m quite optimistic that it’s going to be fun.
96 notes /
