It’s not all wine and roses in the world of utility computing. There are dark corners and hidden “gotchas” lurking behind each of the “big three” (AWS, AppEngine, and Azure) services. Here are a few things to consider before using utility computing in your next project:

Real-World Readiness. Of the three providers, only Amazon is out of beta, and only Amazon is actively supporting real customers at large scales across all of the services they offer. The AppEngine team and community are extremely responsive, and Google has published their post-beta road map, but major pieces still in progress – such as support for a second language – may disrupt their intended timeline. And Azure, of course, is barely open for public experimentation at the moment. It will be a year or two before Azure is a reasonable choice for deployment; expect significant growing pains and changes in that time.

Service-Level Agreements. Or, more specifically, lack thereof. Amazon is ahead of the curve with their S3 and EC2 SLAs; as a result, AWS is the only business-friendly cloud platform out there. AppEngine makes no guarantees about uptime, and in the beta period it is clear that Google is willing to tweak their services in ways that can break running applications for minutes to hours at a time. There seems to be a lot of skepticism in the community about Microsoft’s ability to deliver meaningful up-times, but I think this is hogwash. Microsoft has plenty of experience maintaining data centers – though, of course, we shouldn’t expect Azure SLAs for another year or two.

Cost Structure. Google’s “freemium” pricing is free to an impressive degree. I’ve written an application for AppEngine that I expect will be quite popular – but never popular enough to cost me even a penny. Those are powerful economics! Once you’ve passed the “freemium” threshold, however, AppEngine looks slightly more expensive than Amazon. Of course, Amazon charges the moment you start experimenting with their services; this may be cost-prohibitive for small and independent developers. Microsoft hasn’t yet announced pricing, so you develop on their infrastructure at your future economic peril.

There is one pricing issue specific to AppEngine that has yet to be resolved. The AppEngine team appears to have no firm answer on how they intend to meter CPU usage and on what, specifically, constitutes a high-CPU request. I expect more clarity on this by the time AppEngine exits beta.

No Scalability For Free. With AWS, and to some extent with Azure, the developer must manage scalability by hand. This can be a complex task and there is no silver bullet. AppEngine takes a different approach. By substantially narrowing the type of application that can be built, Google can transparently scale based on demand. Even this “scalability” isn’t free, however. Applications that perform a high percentage of writes but are not properly engineered will fall down under the weight of even ten queries per second. Application code can retry writes if they fail, but often the only correct action is to quickly return an error code to your users. In my experience, working through AppEngine datastore contention issues can be very time-consuming. Good load testing is essential.

Byzantine APIs. Amazon is especially guilty of building APIs that are far more complex than necessary. It simply isn’t possible to “hit the ground running” with Amazon’s more interesting services such as EC2 and EBS. And once you walk up the learning curve for one AWS API, you have to start all over with another. Some of Amazon’s APIs are query-based; some are REST; some are a combination thereof. The documentation is thorough but hard to make day-to-day use of.

Woeful Documentation. Microsoft has done an abysmal job explaining their new Azure platform to developers and businesses alike. After the PDC, it seems that most developers were left scratching their heads. The Azure web site lists “getting started” options for “web,” “corporate,” “ISV,” “system integration,” and “business” developers. Deciding which category you belong to is left as an exercise (in frustration) for the reader. Digging deeper, the most useful overview of Azure turns out to be a sixty-page white paper that reveals most of the Azure initiative (Live Mesh, SQL Cloud Services) to be essentially uninteresting. And once you start to use the service, you have to navigate a torturous web UI that makes a disaster out of even simple tasks like DNS configuration.