Comparing Google App Engine and Amazon EC2 on Technology

Table of contents
Reading Time: 6 minutes

Recently, at a prospective client, we were asked to make a comparison between Amazon EC2 and Google App Engine. Having recently done fairly large-scale projects on both of them, we think that we could make a fairly valid summarization of our thoughts. With this post, I would like to put our thoughts out for consumption and debate.

The three parameters on which I would like to compare the two are

1. Technology benefits
2. Business benefits and
3. Future Trends

Grab a coffee. Let us start.


Most of us know that GAE falls under the category of PaaS and EC2 falls under the category of IaaS. A quick recap of what it means.

Amazon gives 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). Pretty powerful if you want to build a highly complex custom application which plays around with the environmental parameters and is dependent on the underlying OS, storage and network needs. The platform is pretty low-level and you can tweak most of the things to your need.

GAE on the other hand gives you a complete platform, rich with SDK (along with an Eclipse plug-in) and services to build and deploy your application. You do not have fine grain control over the OS, hardware, storage and there are certain limitations like writing to file system, use of threads which ensures that the platform cannot be taken hostage by an application.

In a nutshell,

IaaS: Raw Hardware (Processors, Networks, Storage).
PaaS: OS, System Softwares, Development Framework, Virtual Machines.

Let us compare the two cloud vendors on technology,

  1. Services provided – This is where GAE beats Amazon hands down with the richness of services provided. GAE provides ready to use services which help in rapid application development.These are services like Blobstore, Images, Mail, Memcache, Multitenancy, Oauth, Task Queues, URL Fetch, Users, XMPP For the sake of comparison let us assume that you have to set up your own infrastructure for Memcache, Mail and Multi-tenancy (all M’s). How much time is it going to take for you to install these and start using them. More than a couple of hours I can bet. With GAE, these services are available to you on the platter ready to be consumed. I guess you would agree with me, there is a substantial amount of work which needs to be done in order to make an application multi-tenant. On the other hand, with GAE multi-tenancy support, we could make a non multi-tenant application multi-tenant in a matter of four hours. Impressive isn’t it?
  2. Administration – Here again GAE would take a lead as compared to Amazon, as with GAE there is virtually nil administration that you have to do once your application is deployed. The scaling is provided for free and is built-in. You do not have to pump new instances into service when your application is experiencing load. New instances are spun-off in real-time. With Amazon you would have to keep track of traffic (now automated through scripts) and spin-off new instances on the basis of your configuration. So if my peak load is 2x+ y then spin-off 2 more instances of app server.
    Moreover, with GAE there is no administration overhead of upgrading the app server instances and installing new load balancers as all of that is taken care of automagically.
  3. Abstraction – Closely tied to the above point is the level of abstraction. GAE provides a level of abstraction where you are ONLY worried about your application and the business logic and not about managing the underlying infrastructure. As Nick Johnson put it, as a general rule of thumb pick the platform which is at the highest level of abstraction so that your needs are met without looking under the hood.
    In my view, if your core business is transportation of cargo then would you rather buy a truck which takes you efficiently from point A to B without looking under the hood or would you rather accumulate the parts and build a truck of your own and then transport the cargo.
    In the software world we have seen frameworks like Grails, RoR which provide scaffolding to do the plumbing gain a wide acceptance just because they offer a higher level of abstraction as compared to coding in plain Java.
  4. Reliability –As far as my knowledge both are very reliable options. Both have a huge install base which is growing by the day. App Engine makes it status transparent to the community. Historically, the uptime of Amazon has been better than GAE.
  5. Portability –By the very nature of providing low-level access to the type of OS to use and the development frameworks to use, Amazon is more portable than GAE. However, to dispel the fears of lock in and portability GAE gives out explicit instructions on how to move away from the App Engine platform with all the data that you own. Also applications like AppScale allow applications built on GAE to be ported with ease onto Amazon EC2 or any other cloud for that matter. AppScale is a platform that allows users to deploy and host their own Google App Engine applications. It executes automatically over Amazon EC2 and Eucalyptus as well as Xen and KVM .
  6. Storage –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, MySQL etc which gives you quick and easy development of backend code.
  7. Application Maintenance and Upgrade – is a breeze with GAE. GAE provides with a admin dashboard detailing various aspects of the application, this includes log viewer and data viewer. One application can have multiple versions and you have the capability of making a new version default as soon as it is tested and ready for production. With Amazon you have to take care of most of the administration and upgrades yourself since it is an IaaS.
  8. Development Restrictions – With GAE you would have to deal with restriction that come as a part of the platform. There are hard circuit breakers to kill your query if it is taking too long. No threading. Restricted JDK, there are some classes and features which are blacklisted and hence cannot be used. No writing to the file system. A few more.
    While on the face of it, it may seem absurd but when you are offering platform as a service you have to keep some restrictions so that applications on your platform do not violate the rules of the platform in such a way such that the platform becomes unavailable.
    I would assume that 90% of the business applications would be able to work around these restrictions. In the systems that require heavy use of threading, file system etc the better choice would be to use Amazon with all the low-level capabilities that it would provide.
  9. Languages Supported – Right now GAE supports Java and Python for development with BigTable as the datastore. However, any language which gets converted to bytecode and can execute on the JVM is capable of running on the app engine. If you would like to code on anything else then the best bet is Amazon which would support anything as long as you can install it on the OS and the hardware that they provide. There are many interesting projects done in C#, .NET, ASP.NET MVC / Visual Studio which are hosted on Amazon. The interesting thing is that despite Microsoft Azure being there, a lot of MS based projects are hosted on Amazon, thus making it the platform of choice for these languages.

In a nutshell, Amazon was early in the market, and has leveraged Internet standards and open source platforms to create a very flexible platform. Google is leveraging the work it has done with big databases and its internal development methods to create a powerful but more restrictive environment. At its core, Amazon’s EC2 allows you to scale any computer instance to multiple instances, so you have total control over what’s available on each virtual box. AppEngine abstracts away from the operating system, the concept of a computer instance. If you are building a web application supported by App Engine and these would include the enterprise level applications then the winner is clear as long as you don’t need special functionality from the operating system. If you need more control over your system environment or special OS-specific tools then Amazon EC2 is your preferred way.

In the next post, we would compare the two vendors on business parameters.

Written by 

Vikas is the CEO and Co-Founder of Knoldus Inc. Knoldus does niche Reactive and Big Data product development on Scala, Spark, and Functional Java. Knoldus has a strong focus on software craftsmanship which ensures high-quality software development. It partners with the best in the industry like Lightbend (Scala Ecosystem), Databricks (Spark Ecosystem), Confluent (Kafka) and Datastax (Cassandra). Vikas has been working in the cutting edge tech industry for 20+ years. He was an ardent fan of Java with multiple high load enterprise systems to boast of till he met Scala. His current passions include utilizing the power of Scala, Akka and Play to make Reactive and Big Data systems for niche startups and enterprises who would like to change the way software is developed. To know more, send a mail to or visit

9 thoughts on “Comparing Google App Engine and Amazon EC2 on Technology8 min read

  1. So according to you, which one wins ? google app engine, since most of the points seems to be won by GAE

    1. If you ask me, I would answer in affirmative. Barring a few applications in which we are using machine learning and prediction APIs, all the other business critical applications that we have developed so far are using / can potentially use the power of GAE. As you would have read multiple times, we have to understand the need of the application. And, as per me, more than 80% of the business applications right now can be satisfied with GAE.

    1. Sure we did face the cold startup and believe me, it was a big putoff. We mitigated that issue with a not recommended but workaround nevertheless. There has been talk about reserving the server at a price, you can star that too. This would definitely bring some relief to all of us who think of that being a huge concern.

      But, if we think about it from a different lens. There is a platform which has huge number of applications. This platform has to be optimized in a way such that it can server most of the applications with adequate performance. Now imagine an application which is being hit 5 times a day. Would you reserve a JVM for this? I doubt. I would rather reserve the space and infra for high traffic applications. That is not to say that I like the cold startup. I sure dont and until there is a viable solution it is an onus on the application developers to make sure that cold start times are not huge. We brought down our cold storage spinoff times from over a minute to around 12s. But 12s nevertheless and then we resorted to the hack that I mentioned.

  2. i have found the learning curve for gae is quite high. it’s hard to get used to only using their supported classes and restraints. plus you pretty much have to be using gwt or servlets for easy development on gae (struts2, spring and jsf are a real pain to get working)

    1. Steven, let me put it this way. For most business applications today, it gives you a subset of lightweight tools with an option to use all the heavy weight tools and get your job done. I am sure that you would be able to do the same work with GWT, Guice, Spring Roo/Play framework/Slim3, Objectify/JPA as you would do with the frameworks that you talk about. But, this argument holds good for greenfield development.

      For traditional frameworks, we migrated an application which had Wicket, Spring, Spring Security, Hibernate (which we migrated to JPA) and the only place where we had to make significant changes was as expected, the DAO layer which had to be made compatible with the datastore restrictions.

      So, is the learning curve high? Depends on the frameworks that you are using. For most frameworks I would say no.
      Are there restrictions on the platform? Yes there are and you would know some of them only once you encounter that issue 🙂 and then there would be workarounds

      JSF, probably I have a personal bias 😉 but I would avoid it in a regular application too, leave aside putting it on the cloud. I know it has matured a ton since I used it 4 years back but even last year when I was using it on a project, it felt not that comfortable 😉

  3. The next version of the GAE framework called Tipfy is being developed to allow the app to run outside of App Engine. That may be one way of lessening the feeling of lock-in, as you can develop and deploy on App Engine now, then move to another environment at a later time should you wish.

Comments are closed.