http://evolvingtrends.wordpress.com/2008/07/23/google-app-engine-threat-or-opportunity/

I discuss the use of P2P (distribution) in conjunction with appengine and EC2 but the summary below is with respect to the quota problem in appengine.

Summary:

The problem is that they can’t tell the difference between an infinite loop and a routine that will eventually terminate (on its own.) So they give you a quota to use in a time window of a day or a month (however they’ve decided to define the quota window) and your app can burn as many cpu cycles at any given time, i.e. burst, up to the remaining quota for the given time window (hopefully, without depleting all your quota before the end of the time window.)

For a “massively scalable” cloud computing solution it is very dumb for Google to offer a quota-based “free” account (that maxes out and leave you hanging) unless they are working on a way to examine your code for you (before you run it) for potential infinite loops and badly designed queries.

This may sound banal but the reason for enforcing a quota for the free account is because they want to give you a limited (not infinite) free cpu cycles. The problem with the quota, however, is that once you deplete it, you will have to wait for the next quota window, e.g. 12 hours, a day or a month.

The way to handle this practically is for Google to do away with the quota model (e.g. bill you for all usage) or come up with sophisticated statistical techniques to examine your code for potential infinite loops or costly queries (remember that Turing already proved that you can’t always deduce that logically) before they run it. Without such ability, applied in reliable manner, the only thing they can do when your app inadvertently hits the quota for the given time window is to disable your application until the start of the next quota window, which totally sucks.

—

What am I missing? Isn’t this an obvious Google Duh! moment?

S3 may have gone down, but like last time, it’s probably for something other than machine availability. After all, Amazon uses multiple physical hosting locations. So does Google. But if GAE goes down, it’s down everywhere.

The real point, though, I think is that these commodity providers are providing scalability at prices that an individual can’t compete with. If you want a better up time than AWS or GAE then you have to lease multiple rack locations with multiple computers and multiple backup DNS servers that self heal and redirect on errors. Getting all of that in place is costly.

To use Aral’s example of power, getting in place generators and UPSs to weather any sized power outage and equipment failure is also expensive.

What we’re missing from GAE and AWS is the ability to do this. Or are we? One might argue that having your own server in the mix is the backup plan. For S3, that’s pretty easy — just have an alternate URI mapping for when S3 doesn’t respond. Instead of your own server, though, it could also be a different cloud. An EC2 app could, by default, use S3 for image hosting but fall back on images sourced from Google (GAE or or sites or something).

Expecting a single cloud offering to do this is too much, though. Right?

The reason you won’t see lots of competitors in this space is economies of scale. Amazon can provide the services dramatically cheaper than anyone besides Google, Yahoo!, and Microsoft. There will be only 2-5 players in this space, since nobody else could afford to price competitively without taking massive losses. In a situation like this, interop matters a lot, and Amazon is the de facto standard by a *wide* margin. I don’t doubt that Google will eventually make strides toward interop for apps written on Amazon — it is the classic underdog strategy and would help them steal business. But they haven’t yet, and I don’t think it’s a priority for them yet.