Dare Obasanjao recently asked “Is Google App Engine the wrong product for, the market?” and then tried to answer the question in a blog post.
He concludes, rightly, I think, that it’s certainly the wrong thing for “enterprise developers,” and gives a good rundown of the issues web developers trying to use it now will face in having to deal with its non-relational datastore, and restricted Python centered development environment.
I’m coming at it from a different direction, wondering what Google AppEngine is good for and I see at least two classes of applications:
- Small, focused applications that are developed quickly and expected to live hard and die young (lots of traffic for a short amount of time). Something intended to spread quickly, like a lot of facebook apps or MySpace widgets. The sort of app that a designer and one or two developers could do in a month or less. With those sorts of time-frames, building an infrastructure that could scale up and down quickly wouldn’t be hard to justify, even using something like Amazon EC2.
- Installable apps with just a few users (like a private Wiki) that wouldn’t justify the expense and upkeep of even a small Virtual Private Server, but which are valuable enough that people wouldn’t want to depend on some startup remaining in business to keep their data available. If people installed the app on their own AppEngine account, then they could be reasonably sure their data would be accessible even if the original developers abandoned the project.
- Installable apps with the potential of spiking to a whole lot of users, like a public blog, etc. Again, depending on Google for hosting would be easier to swallow than some startup that could vanish.
- Federated apps. Users would control their own data via their own personal installed instance, but would also take advantage of services that create a network of all the installations. For example, imagine an application that people would invest a significant amount of work in, maybe something like Twitter. Their personal data would be in their own instance, but it would tie in to a larger Twitter network for interuser communication, and emergent features, like app-wide search. If the startup providing the core services went away, the end user would still have all the content entered into their profile, and, potentially, their existing social graph.