Rowland Watkins

Is the Google App Engine a viable competitor to the current generation AWS?

To first approximation, I would argue no. As a Python (for the time being) web application platform, Google App Engine provides a highly scalable sandboxed environment that reduces what a developer can do with the underlying platform. In addition, the Google App Engine is a single Software as a Service (SaaS) platform. Developers and businesses cannot reuse distinct services for deploying OS images, storing data, creating complex business processes.

AWS on the other hand, is a low-level middleware infrastructure for developing new platforms. It provides primitive services for storage (S3), databases (SimpleDB), queuing (SQS), and computation (EC2) that enable high resilience and scalability. Consider Morph eXchange which offers Rails app hosting as a SaaS in a very similar fashion to the Google App Engine. And guess what, it actually runs on AWS! Unlike Google App Engine, however, Morph appears to allow businesses a free-er hand in their development decisions, permitting a full Ruby and Rails environment, together with managed access to S3.

The clear separation of duty in AWS is what gives it the edge over Google App Engine. EC2 allows businesses to deploy complete OS images from S3 to produce novel environments such as Morph. It gives business more control on how to put together business processes which currently isn’t possible with the Google App Engine.

Google App Engine is still in closed beta so it’s early days. It’s possible it will pick up and enable business to do things not possible in AWS. Then we would have competition and even more innovation at our finger tips.

Google have taken a first step by exposing part of their infrastructure capability through their new [invitation-only] Google App Engine. It’s a Python-based infrastructure that provides access to many core services using by Google – more information here.

While I haven’t been lucky enough to get to the head of the waiting list, I have played around with the SDK released by Google, which offers a complete development environment, including a development server. I haven’t utilised all interfaces yet, just looking at what Google offers in terms of interfaces for remote connections to other WWW services.

Google have been quite sensible in creating a sandbox for running potentially hazardous third-party developer code, removing access to many core Python modules that use C interfaces. This is OK, until you want to do something exciting like HTTPS GET – urlfetch will perform the GET, but has no way of validating the server. That’s not too bad, but it’s not clear if urlfetch even provides the ability to access the TLS session and for the developer to validate the certificate themself – seems like a valid alternative.

It would be nice if Google at least loosen the rope a little more to provide full TLS functionality. Of course, what I really want to do is TLS with mutual auth – that should be good fun. In the mean time, I’ll see what I can do with other TLS toolkits that run in pure Python.