Alex Bosworth's Weblog
Wednesday - Apr 09, 2008
AWS vs Google App Engine

I was recently invited to a Google Campfire meet, but unfortunately it’s a long commute from Beijing, so I had to read about their big announcement on a bajillion blogs: Google is now in the application hosting market.

I’m guessing this is related to their purchase of Jotspot a while back, but it’s definitely something I’ve hoped for – as someone who is building an application on the AWS stack, I want to see competition in application hosting.

To be succinct, based on where the Google App Engine is today, I would say AWS still has a strong lead in application hosting, and I would not currently consider writing an application for Google’s current platform.

Sure the AWS stack has a lot of problems, but the core 2 services: S3 and EC2 are time tested and very solid offerings. They don’t always hold your hand, but if you work around some quirks in the system you can get whatever you want done.

Google App Engine as it currently stands has several flaws:
  • Lockin – you are locked in to their platform. If you build an app on Google, you better be sure what works for you today will work even if your circumstances change, or if Google changes their mind about the profit opportunities in web-hosting.
  • The page-view limitation is quite low – millions of pageviews come quicker than you think.
  • I didn’t see memcache on offer – that might be an oversight but I have learned my lesson and will not build another production website without memcache ever again.
  • No long running pages, or cron jobs – remember even if you don’t need this today, you might tomorrow. Almost all of the web apps i’ve ever written require long running processes or cron jobs of some kind.
  • Storage size limitation – you never know how popular your site will be. It’s a tragedy when you write yourself into a scalability corner, they don’t offer you very much space.
  • One language – 1 language does not fit all purposes. I’m hoping they increase the number of languages, I’ve looked at Python and see no compelling reason to switch from PHP 5, although I think both languages are good very choices for web development.
  • To use your own domain you must use Google Apps
  • No requests unless they are through Google’s API. This means you can’t do things like host another type of server, or even fetch a remote webpage running on a nonstandard port. You can also not fetch remote webpages that are behind redirects. Also any library you have that includes http fetching technology, such as an RSS library or something, will break and need patching.

That being said: it’s free. To developers, free looks pretty rocking, and I’m sure that many apps will be written on this platform.

Also, it integrates with Google accounts – a very nice feature, it would be nice of Amazon to do the same, particularly when it comes to payment processing.

I would also prefer Google Bigtable to Amazon Simpledb – which currently cannot sort results, although you can get more than 1000 results for a query. GQL also beats simpledb by supporting paging, numbers, and no apparent limitations like 255 values for a row. You can also get back rows from a query, instead of being forced to issue new requests for each row.

The email service also seems like it might be nice, I’ve heard that emails sent from EC2 servers are often marked as spam – I’m hopeful that filters would be kinder to Google ip sent emails, although they might have the same problem.

One thing both Amazon and Google could do to really show they are serious about their platforms is open up their data engines, which are really the core of most web applications – open source bigtable and simpledb. This would really reduce lockin and make development easier, and it might even lead to some help improving their services.

(This post has been read 2276 times.)

Comments (3) Add Comment
Frameworks and ORMs create portability
Posted By: Niall Kennedy Apr 11, 2008 12:13:30
Frameworks such as Django will help developers achieve some degree of portability on Google App Engine. The ORM layer handles requests based on PostgreSQL or BigTable and the rest of your code can stay agnostic. Libs such as urlfetch or mail are Google-specific but perhaps not a bad abstraction layer to have in all your apps.

To use your own domain you must first verify domain ownership through Google Apps. You don't actually have to use any of the Apps for your Domain services, just create a CNAME record for the shared secret.

Redirects can be handled through urlfetch but it's not an automatic process. You'll have to loop. Was your response a 301? OK, time to send another request for that new location.
Well what do you think? Post a comment.

Title:

Name:

URL:

Comment: