I am a simple caveman web app developer. Your scalable racks frighten and confuse me. But, there is one thing I do know. I have code. I have data. And I must put that code and data online as quickly as possible.
Both AppHarbor and Heroku provide deployment using Git. This is elegant. I expect to see more services offering both continuous integration and live deployment via source control.
AppHarbor is for ASP.NET code. Heroku is for Ruby on Rails.
For now, Heroku and Rails lead the way. But, AppHarbor and .NET are catching up quickly.
The code.
Round 1.
Fight!
AppHarbor provides some continuous integration features. It runs your unit tests prior to deployment. If a test fails, the software does not get deployed. It also provides a list of recent builds, which you may click to deploy. Heroku does not provide these features.
What about debugging your live code? Heroku wins this one. Heroku automatically logs exceptions. It provides a couple different logging options. AppHarbor provides a page for "Errors", but throw as I might, I've never seen it say anything but "No errors to display." They currently recommend you roll your own error logging.
Heroku also recently rolled out a feature to help with managing Staging and Production environments. This is a highly requested feature on AppHarbor, so I expect we will see it soon there.
Finally, what about writing code? This goes to AppHarbor (well, actually to Microsoft). Visual Studio simply provides more assistance to the developer. With Ruby on Rails you will be installing more tools and spending more time at the console. And Code Completion? Visual Studio beats the Ruby development environments. (Can a dynamically typed language can ever offer as much code completion as a statically typed language?)
AppHarbor wins (but not without taking a few licks).
The data.
Round 2.
Fight!
One of the corner stones of Rails is "Convention over Configuration", and this is most evident with its ActiveRecord based ORM.
Using .NET on the other hand... Well... There are many options for data access. And they certainly use conventions. But, none is without some configuration. And AppHarbor offers no clear recommendation. This is a brick wall to beginner adopters.
And schema migrations? Rails wins again. Heroku handles migrations the same way they are handled locally: by calling a rake command. The code and schema stay naturally in sync as the migrations are stored in text files alongside the source.
AppHarbor is very different. Databases are created manually via the web interface. Databases cannot be added or dropped at runtime from the application.
Furthermore, Microsoft's Entity Framework is not there yet either. Using the EF Code First approach (which seems to be the path of least resistance) the only "migration" supported is dropping the database, and creating an entirely new one. Clearly this nuclear option won't work with AppHarbor's policy, or if you want to keep your data. (There is a work-around that only drops the tables. I ended up creating my tables manually with a sql script exported from my local database.)
Another database bootstrapping problem that new MVC3 projects will run into is the absence of Application Services tables. These services can be removed from a new MVC project, or you can populate the remote database as described in this thread.
Heroku wins. Flawless victory.
Round 3?
The conclusion is that Heroku is faster overall, particularly for database deployment. But, AppHarbor, Microsoft, and open-source .NET developers are closing the gap.
No comments:
Post a Comment