Clojure Web Application: EC2 or GAE

amazon ec2clojuregoogle-app-engine

I am developing a web application written in Clojure using the Compojure framework. My question is, should I deploy to Amazon EC2 or Google App Engine?

I've read this article on running Clojure code on GAE, but I am still a bit concerned about the limitations on GAE. I am going to be running sandboxed Clojure code, which means I might end up needing to tinker with the JVM security policies.

With EC2, I'll obviously have full control of everything. The downside is that this means more of an effort from a sys admin perspective.

I'm not sure which option makes more fiscal sense. I am not expecting too much traffic initially, and suspect that I'll operate pretty close to the "free" tier/quotas on either service.

I've had a lot of success working with EC2 in the past, but at the same time I'd love to get some experience with Google App Engine (which I've never used).

So whats your vote: Amazon EC2 or Google App Engine?

Best Answer

While I won't claim enough experience with either environment to answer your question fully, if you're considering Clojure on GAE you may find appengine-magic useful:

https://github.com/gcv/appengine-magic

As an aside, the database limitations, performance, and costs are worth looking at closely with either platform, and may convince you (as it did me) to avoid both. For example, see these stories:

http://www-cs-students.stanford.edu/~silver/gae.html
http://news.ycombinator.com/item?id=2340286
Costs comparison: http://matthewphiong.com/price-war-linode-vs-slicehost-vs-amazon-ec2-v

Related Solutions

Windows Azure vs Amazon EC2 vs Google App Engine

I've written the same app on GAE (Python and now Java) and Azure. I'll probably continue to use both, for different things. Here are a few thoughts that I'll keep updating:

Reasons to use GAE:

You essentially get one free VM's worth of use per day. With Azure, you pay almost $100 each month, even if you don't have a single website visitor. If your db goes over 1GB, you pay an extra $90 ($9->$99) for storage. Update: Azure now has various VM and DB sizes at different price points. Details here.

GAE's payment is reasonably fine-grained - most resources are charged per request/GB/MB, again with a free daily allocation for most resources. However, in November 2011 it joined Azure and AWS in charging for the web server per instance-hour. Details here.

GAE has the lightest admin load. Once you're setup, deploying and re-deploying is quick and they'll auto-everything. For example, you don't worry about how many servers your app is using, how to shard the data, how to load-balance.

Mail just works. At the time of writing, Azure doesn't offer SMTP out so you need a 3rd party server.

Great integration with many of the Google offerings - calendars, mail, whatever. You can delegate user management to Google if you don't want control over your user base.

With GAE you know any features they add to the store, you'll get. With Azure, you get the feeling Sql Azure Database will get most of the love but it'll be more expensive. Azure Storage is likely to have the most gotchas. No relational integrity, no order-by, you'll fiddle with the in-memory context more. GAE's store has far fewer restrictions and more features than Azure Tables.

Good choice if you're using Python or JVM-based languages already. Many languages compile to Java bytecode nowadays.

Updating the app is very fast. For Python, I had a shortcut key setup and it took no time at all. I now use the Eclipse Plugin for Java and it works very well. Azure is more fiddly.

A locally tested app will probably run on the cloud without (much or any) changes. With Azure, the config is different and I spent some time stopping-deleting-building-uploading-starting before I got it right.

GAE has a great UI that includes a log viewer a data editor. With Azure, you currently have to find external viewers/editors for this.

GAE lets you have multiple versions of your application running on the same datastore. You can deploy, test a version and then set the current 'live' version when you're ready. You can change back if something goes wrong.

Reasons to use Azure:

The performance characteristics and cost implications of App Engine's datastore will surprise you. If you do anything other than simple CRUD you'll need to work harder than you would with a normal DB. No ad-hoc queries.

Azure has two approaches to storage, offering more choice. They are SQL Azure Database (SAD) which is a relational DB, and Azure Storage, which consists of non-relational tables, blobs and queues. If you have an investment in SQL Server then SAD will be easy to move to, but is quite costly and might be less scalable. Update: App Engine has a MySQL API in limited beta.

Azure seems to be better designed if you have a SOA-type approach. Their architectures seem to benefit from experience in the enterprise world. GAE seems more focused on simply serving web pages.

You can run the app under debug, put in breakpoints, etc.

Azure has a "staging" environment where you can deploy to the cloud, but not make it live until you're happy it works.

I'm using .Net for other things, and integrating them with .Net on the backend is much easier than with GAE. (Update - using Java on GAE works fine, and the 10-second timeout is now 30 seconds).

Integration with many MS "Live" offerings.

So, no obvious answers. I'm defaulting to App Engine at the moment because of costs and ease of use. I might use Azure for very MS-oriented apps. I use Amazon S3 for downloads but likely won't use EC2 because I prefer leaving everything under the application level to the experts.

Cloud Services – Advice on Cloud Service and IM Protocol for Group Chat Mobile App

Protocol

Yes, this is going to sound like a cop-out but it's really up to you. Honestly, what you've described sounds a heck of a lot like IRC, but XMPP is quite extensible and widely used, so it's probably the easiest non-IRC to get working and to get support for. You're going to be able to find a lot of examples for both platforms, and likely even already-prepared libraries, if you want to go that direction. I'm not going to go recommend any, but a quick search should be a very useful tool here. There's no one right answer, but XMPP is certainly not a bad choice.

Cloud Service

Both Azure and AWS are very good services. A lot of high-profile or important applications run on each of them. One of the reasons I tend to favor Azure over AWS, however, is that Microsoft really tries to make it easy for you to get it. If you haven't yet, I would look into Bizspark, which, if you get approved for, will give you, among other things, a free small instance of Azure. To be fair, Amazon does the same kind of thing, but they seem to give you a little bit less, and only for a year (Bizspark is for 3 years). On the other hand, Bizspark actually requires that you get approved, while Amazon really just gives it to you pretty easily.

All in all, either is really a good service to go with, and both Microsoft and Amazon tend to be very committed to helping developers get things done, so you can't go wrong either way. The best way of deciding is to look at the features they offer compared to what you need, and the pricing for your minimum and ideal levels. For example, if you did want to support Windows Phone, Azure might be a better option, because they work well together, but if you wanted to leverage fulfilment services and ship tshirts or coffee mugs or anything like that in connection, Amazon might be the better choice (Note: Don't read into either of these; I purposely picked two scenarios that you didn't mention just to give an example of some of the unique features of the services.)

As for the Elastic Load Balancing and Auto Scaling, that's just AWS branding what cloud servers in general do. All decent cloud services will make scaling your system technologically negligible, at least from their side (if you happen to have bad code that doesn't scale well, you can't really blame it on them...). So yes, those are good things, but everyone has them, so they shouldn't be a decision maker.