Comparison of Amazon EC2 & Google App Engine GAE/J

After spending few weeks with some of the Cloud services and reading the comparisons between them, I felt tempted to jot down my own views about atleast two of them.

Firstly, hands down to Google for providing such a brilliant service for free. It gives developers great opportunity to try new things and bring it infront of the people without investing huge amount on that. It also helps Small Business Enterprises to not invest huge into infrastructure and develop application on such a robust platform which is highly scalable without you need to get into the network setup and infrastructure. Not to leave Amazon EC2 services which are a great advantage for people/enterprise who wants to launch a product without investing on the network infrastructure and still being scalable and add more systems when demand increases.

Now on the comparison side, in my view two services are totally different, they may give you the same advantage of you not investing huge into the infrastructure, but they both have their own usages.

Introduction: EC2 service give you access to the boxes in the cloud with the operating system and you do the whole setup required for your application, or you can use the AMI(Amazon Machine Image) and yes even in the AMI’s you can configure your own security if desired.  whereas on the same lines Google doesn’t do that instead you create the application and just ask the App Engine SDK(which also comes an Eclipse plugin) to deploy it, it will deploy the application to one or more of the Google Cloud infrastructure instances and you can access the same once you login into your App Engine url. So in a nutshell, you have full control over Amazon EC2 and you can scale any computer instance to n-instances, whereas App Engine abstracts the instances from the developer and uses SDK for an interface between the developer and the Systems.

Lockin: Here i would like to bring third player Salesforce.com into the picture and then compare all of them. Also as previously mentioned you have complete control over the Amazon EC2 system which might or might not be completely true incase of App Engine as appengine provides lot of services which uses its proprietary api which if used locks you into App Engine, but it has its own advantages which I will discuss later. Similarly Salesforce force.com is mostly locked in as you use its own api to develop and deploy the their cloud. Salesforce has its own custom language and its own SQL/ORM layer.

ThoughtClicks - Comparision of App Engine, EC2 & force.com

Cost Factor: This is one of the important factor need to be considered when deciding between these two choices. Google App Engine has a free quota which is sufficient for applications with around 1 million page views. You can also enable the billing account once you go beyond that point & billing account is also reasonable, Price is based on CPU/hr, Outgoing/Incoming bandwidth, store data & number of emails exchanged etc. Google App Engine Billing Quota Unit Cost. On the other hand Amazon EC2 Services comes with a cost which is again nominal but no free stuff instead pay as you go. You can look at the pricing plan for Amazon EC2 here. but on top of EC2, if you persist some data you need to pay have EBS volume and it again comes for  cost after 1GB and costs $0.10 per GB-month & $0.10 per 1 million I/O requests, which is again very reasonable.

Services Infrastructure: Here Google App Engine gets an edge as it provides lot of ready to use services which comes very handy when you want your application to be up & running quickly, This all doesn’t comes for free instead if you use any of these services they are totally  based on proprietary api which locks you in Google App Engine. Some of the commonly used services are as follows.
1) Memcache – Ready to use cache already available on App Engine Servers, you can use JSR 107 api to 
    add or remove objects from this cache, so this comes as a nice feature without lockin.
2) XMPP – Can be used to talk to any XMPP enable clients like jabber etc.(Proprietary API)
3) Task Queues – This can be used like jms queues to handle tasks without user keep waiting. (Proprietary
    API)
4) Mail – It is again one of the feature which can be used using Java Mail api
5) Cron jobs – You can also run cron jobs in your application(Proprietary API)
6) Authorization – App Engine also give you OAuth out of the box and it can be very easily implemented in
    your application.
As far as i know Amazon, on the other hand doesn’t provides any of its services readily on the system except the mail or maybe cron, but it doesn’t either limits you from creating any such service the way you want.

Reliability: As far as my knowledge both are very reliable options except last year in june when once Appengine was down for more then couple of hours. and both have

Datastore: Appengine at present heavily relies on Bigtable, for which developer needs to think from a totally different angle then how we all are use to using relational databases. It has a JPA & JDO api to access it but it doesn’t supports all the JPA & JDO feature specially the relations part of it. Google also have recently announced that they will soon be launching the App Engine for business with proper SQL Support but again as Amazon it comes at a cost. where as on Amazon EC2 it all boils down to you choice of SQL database you want to use. You can use Oracle, My sql etc which gives you quick and easy development of backend code.

One of my experience using Google App Engine is that it a great resource for a person to kickstart stuff but once product get matured you might want a little bit of more control then provided. Having used Google App Engine for quite some time now, one of the major drawbacks i felt with Google App Engine atleast on the free version is that it recycles the applications very aggressively. Incase your application has very less traffic then you application has very high chances of being brought down when not in use and restarted when the request comes in, this leads to slow response on the initial requests. Developers including me have already requested Google to find different solutions for this. Out of which one is “Pay to reserve a JVM” Please help us by starring this issue.

Also Please keep in mind that Google App Engine does not support complete Java stack instead it does support the complete JRE Class whitelist which enables you to play around with the following Java EE Technologies.

For any issues or support related to App Engine or EC2 you can contact us at: cloud@thoughtclicks.com

6 comments:

June 23, 2010 at 11:57 AM Anonymous said...

You may also want to read http://bit.ly/95TxPB which brings Microsoft's Windows Azure Platform into the picture.

June 23, 2010 at 2:45 PM Anonymous said...

1. XMPP is not proprietary... it's an open instant messaging protocol: http://en.wikipedia.org/wiki/Xmpp ... *any* IM platform will be able to communicate to/from an App Engine app as long as it speaks XMPP.

2. OAuth stands for "open authorization" not authentication -- you're referring to OpenID (which App Engine also offers). please do not confuse readers b/w the terms authentication (user identities) and authorization (data/API access). yes, sometimes you can combine them for 1-step data access, but mention that instead of giving an inaccurate definition.

3. as the other commenter has stated, your article/review will be more complete with Azure in the picture

June 23, 2010 at 3:07 PM Anonymous said...

If you were to include Python App Engine, you can expand the App Engine polygon to have a finger into the full portability "terdrant" (not quite a quadrant since there are only 3 columns) as those who create pure Django apps can move them off App Engine (or onto App Engine) to(from) a pure Django (plus RDBMS or non-relational DB) stack at any ISP/datacenter/colo by using django-nonrel + djangoappengine -- see http://allbuttonspressed.com

June 23, 2010 at 4:24 PM Rahul Juneja said...

Firstly, thanks everybody for leaving your feedback.

2 - Anonymous: Firstly yes you are right it is Authorization and I have changed that in the article and regarding the XMPP I agree that it is a standard but google appengine has its own implementation of the specification, which you cannot carry with you, so if you want to migrate to other environment, you will need to use some open api implementation.

January 9, 2011 at 2:25 PM Maxim Veksler said...

Rahul Juneja,

Doesn't AppScale provide that migration path?

March 3, 2011 at 3:00 PM Rahul Juneja said...

Maxim - I am not sure of AppScale but it looks like an open source project, although it does allows users to deploy and host their own Google App Engine applications but it might not be into active development everytime and further development to the apps may not be very clean. But Yes, I have to agree this is a good platform for migrating a small app.

Post a Comment