Google App Engine
Google App Engine, Google’s virtualized cloud computing infrastructure that competes with Amazon’s AWS, is very exciting, but has a long way to go before it becomes a compelling option. We use Amazon’s computing and storage (EC2 & S3) for commandshift3.com, and it has been an excellent experience with no gotchas and excellent support from Amazon’s team. GAE’s high-level approach to computing will someday become more compelling than the virtual hosting-based AWS approach, but it simply hasn’t happened yet.
With AWS, we never have to worry about hardware or capacity, and when we want more computing power, we ‘turn on’ another virtual machine. AWS, however, has real limitations: We still have to load-balance our computing, which means writing our software so it can be run across multiple machines, installing packages, checking OS compatibility, managing UNIX permissions, and on and on, all of which is very time-consuming. I’ve heard of a couple projects that will abstract these limits, but AFAIK, these are still very early in development and require quite a bit of work to get going. (If I’m wrong about this, please let me know).
I’ve been playing with Google App Engine, and fundamentally, they’ve got a better solution than the current incarnation of AWS. In GAE, CPU is allocated to my app on demand behind the scenes, and I never have to think about the underlying computer(s) in the network. Just as S3 gives me storage on demand regardless of scale, GAE gives me BOTH storage AND CPU at an unlimited scale. Additionally, GAE promises to remove me from important limits and details of my database with their BigTable offering.
The GAE rub is that Google has restricted what can be run on its network. Where Amazon lets me install whatever I want on a virtual computer, GAE only lets me run libraries that Google has adapted for their infrastructure. And this list is currently severely limited. In my experience, 90% of any application will use perfectly standard libraries, but the value add comes with that last 10%. Without that long tail of libraries in GAE, I’m so close to being able to write any app at any scale, but will never be able to get the tools I need to actually make it happen. You could argue that BigTable has no substitute outside of GAE, and alone proves its value, but I think that MySQL has proven so flexible and scaleable that at this time the benefits of BigTable rarely justify GAE’s other costs.
If they continue to invest here, and they surely should, Google will solve these limits. But at this moment, in mid-2008, they have a long way to go. I expect that two years from now, GAE will support a much more flexible library set (probably a method for installing various platform libraries that they virtualize for you), and will be able to run more than just Python.
Fortunately, it is quite easy to see if any application in your mind’s eye will benefit from the ease of GAE with it’s current limitations. The decision is so binary that a simple list of required libraries and database demands will show very quickly if GAE is a viable option.
