Admittedly I’m a little late to the party, if only because Mother and I were still collating. If you’ve been living on another planet for the past week, here’s what you missed out on: to much fanfare and criticism, Google recently announced App Engine, a platform to “run your Web applications on Google’s infrastructure.”

The Genius

It’s been expected for quite some time that Google would compete with Amazon’s cloud computing offerings. Big companies make immense investments in developing highly scalable architectures, and it certainly makes sense to offset those costs by leasing the underlying technology to others.

Since the launch of Simple Storage Service (S3) in March 2006, Amazon has absolutely mopped up in this space. They continue to innovate on a seemingly daily basis, and Google chose wisely not to attempt a game of catch up. Instead they stuck to what they know best: distributed computing using BigTable, MapReduce, and Python. While Amazon’s cloud computing offerings are flexible enough to accommodate a wide variety of uses, developing on AppEngine serves only one goal: creating an infinitely scalable application from day one.

You mean no servers or deployment problems to worry about? Sign me up!!!

The Danger

Not so fast kid. Scaling is a problem most engineers wish they had. And such is the true genius of Google’s approach: it appeals to the emotional as opposed to the rational. Research has proven time and time again that people tend to buy primarily for emotional reasons, and Google didn’t get to where they are today by ignoring this fact. Only after an emotional decision has been made do rationalities begin to form: seamless integration with other Google services, creativity spurred by limitations, and even the possibility of a reduced barrier to acquisition by the Big G itself.

As sexy as scaling problems might be, they just aren’t that common. Twitter aside (you’re always going to have an edge case), most web services will never reach the performance limitations AppEngine aims to solve. It’s tempting to imagine hundreds of thousands of people flooding your new service only days after it launches, but that’s probably not going to happen.

And finally we reach the practical. Premature optimization is an evil, evil scourge that can kill a project before it gains traction. Designing an infinitely scalable system from the very beginning is hard–really hard–which is why Google continues its hiring rampage despite the fact that it already employs thousands of engineers. Even with such a substantial platform like AppEngine to build on, porting an existing application takes months or years, as evidenced by the time it took to integrate MeasureMap’s concepts (acquired Feb 2006) to Google Analytics (updated May 2007). Not surprisingly, many of these ports lead to brick walls. Just ask Dennis Crowley, whose presence-aware Dodgeball site languished under Google’s technical complexity. Now presence-aware web apps are all the rage and Dodgeball is left out in the cold.

AppEngine is billed as easy and liberating for developers. Worry about your code and Google will handle the rest. While that isn’t a lie, it’s a red herring. The lack of a relational database makes sorting result sets hard, and simple operations like MySQL’s AVG() are impossible without some kind of indexing layer in between. That’s just one example of how AppEngine simply replaces one problem with another.

In the context of creating a new web service, scaling is one of the last things to worry about. Gathering an audience is a much harder problem to solve, and building it doesn’t mean they will come. Thinking big is what entrepreneurs are hardwired to do, but making it a development mantra is resource intensive and borders on suicide.

The Outcome

There are only two possible outcomes for AppEngine. Either Google (or a middleman) will release new tools that model many of the features of traditional development environments (relational data modeling, caching, process scheduling, etc), or thousands of developers will embrace the platform, only to discover lust for premature optimization as a crippling blow to their projects’ success.

Considering that Google love is in such abundance, the former is the most likely scenario. Once again Google proves its brilliance by analyzing the market and designing a strategy which plays to all its strengths and sidelines all other concerns.

And there you have it, a strategic recipe for success. If you’re not already following the same approach, why not?