http://www.developer.com/

Back to article

Google App Engine vs. Amazon Web Services: The Developer Challenges


March 28, 2010

Sure, cloud computing platforms free developers from scalability and deployment issues, allowing them to spend more time actually writing web applications and services. But when choosing between two prominent platforms, Google App Engine and Amazon Web Services (AWS), which platform is best for you?

The choice can be simple if you fall into one of the following two scenarios:

  • If your application can be architected to run within the limited Google App Engine runtime environment, then take advantage of Google's lower hosting costs.
  • If you need a more flexible cloud deployment platform, then AWS is a good fit for your needs.

Of course, you need to consider more issues than these when making a choice. In my development work, I've had the opportunity to use both and I can tell you that they require very different architecture decisions and present different sets of challenges. In this article, I will discuss some of the main challenges in more detail.

I assume you have a good understanding of Google App Engine and AWS. If not, read my previous articles "Google App Engine: What Is It Good For?" and "Amazon Web Services: A Developer Primer."

Google App Engine Challenges

Because Google App Engine is designed to scale your web applications -- adding server instances as needed -- some HTTP requests may require loading a server instance before the request can be satisfied. Google refers to these as "loading requests." The time required for loading requests varies, based on lots of comments on Google App Engine discussion groups and message boards. The smallest loading request times are reported for Python + DJango web applications (usually much less than a second). Java loading times are much longer, but they are still often less than a second. Google is implementing pre-loading options for Java that will improve the load time performance in the future.

Loading time for new virtual instances is a problem for other JVM languages, often requiring many seconds for JRuby and Clojure. Loading times for Scala are close to that for plain Java because compiled Scala class files are essentially indistinguishable from compile Java code. The difference is caused by code generated to support dynamic languages like JRuby and Clojure on the JVM. For applications running on dedicated servers, this extra load time is not a problem but it does affect applications hosted on Google App Engine. While I have experimented with JRuby and Clojure web applications on Google App Engine, at this time I would choose Python, Java, or Scala for production use.

The bottom line is using Google App Engine will be more restrictive than the development and deployment environments that you are used to. The datastore is more difficult to use than a relational database (which for example has global transactions, joins on tables, and a subset of the types of queries that you can do with a relational database). Not being able to start and manage long-running processes also makes some kinds of applications difficult to write.

AWS Challenges

In my experience, the most difficult performance problems with AWS occur when operations (such as using SimpleDB, file access to Elastic Block Storage volumes, or satisfying HTTP requests) slow down. The detective work of determining whether the problem is specific to your application or is an AWS platform issue is quite a challenge.

Compared with Google App Engine, which requires almost no administration tasks (almost all your work is in application development), using AWS carries some administration and deployment costs. While using AWS is much less effort than maintaining your own server farm, the costs of effectively using AWS for complex web applications partitioned over many servers in multiple availability zones can mean substantial system administration time. However, Google's App Engine has suffered several short breaks in service, so the additional admin cost for AWS probably pays off with more reliable service for your web application users (in my opinion).

On the data storage front, Amazon's SimpleDB is very similar to the Google App Engine datastore in that it is very reliable (won't lose data) and highly scalable (requiring no effort at all from you), and it provides schema-free data storage. However, it also shares some of the inconveniences of the Google App Engine datastore for developers who are used to using relational databases.

An Alternative for Ruby Developers

If you are a Ruby on Rails developer, a good compromise is to use the Heroku deployment platform (which itself runs on AWS). Using Heroku reduces administrative requirements to almost nothing (much easier even than administering Google App Engine applications). I also like to run a Rails application on Heroku along with my own web services running on AWS. If the web services you need to support a Rails application are modest, a single small Elastic Compute Cloud (EC2) instance is probably adequate. See my Developer.com articles on using Heroku with MongoDB and CouchDB remote services.

The Wrapup

Both Google App Engine and AWS are very good resources for writing and deploying scalable applications "in the cloud." Hopefully, this article will help you to decide which platform to choose.

For Further Reading

  • AppScale is an open source Google App Engine implementation written at UCSB. It uses MongoDB, Cassandra, MySQL, HBase, Voldemort, and MemcacheDB as database back ends. The availability of AppScale makes it possible to move your applications off of Google's infrastructure using your own server cluster or Amazon EC2.
  • A video from Google I/O 2009 demonstrates an effective approach to using the Google App Engine datastore.
  • The Amazon documentation for AWS is excellent.
  • About the Author

    Mark Watson is a consultant living in the mountains of Central Arizona with his wife Carol and a very feisty Meyers Parrot. He specializes in web applications, text mining, and artificial intelligence. He is the author of 16 books and writes both a technology blog and an artificial intelligence blog at www.markwatson.com.

    Sitemap | Contact Us

    Thanks for your registration, follow us on our social networks to keep up-to-date