One important but less discussed trend made possible by cloud computing is the number of useful "database community websites" being published. Such a site is similiar to a wiki in how the site's data content is provided by the users themselves. The sites are free to all who want to search the database and to post new data. The sites are made possible by the use of cloud databases, Software-as-a-Service solutions designed to make web database publishing quick, simple and cheap. Here are two good examples of database community sites:

www.PhotoEnforced.com - this site publishes a database of locations where cameras are used at street intersections to photograph violators.

www.GasPricesCentral.com - this site publishes a database of gas prices in metro areas around the country.

These kinds of sites are serving a public need by distributing useful data openly through the cloud. This is just one area where cloud computing is making
a difference.

"I believe that walled gardens will ultimately be overshadowed by clouds because you cannot achieve webscale computing if every application has to run on a server owned by Google."

Um...but...Google is kind of the *definition* of webscale computing, isn't it? If they can't scale your application, who can?

Also, is an open source API still a walled garden? If 5 businesses are build that replicate the Google model in other datacenters (including, perhaps, EC2...already done in prototype), then haven't the walls crumbled?

I, alternatively, see the problem as one of Google building its own "solar system", with a cluster of options centered around its model. Amazon, too, has proprietary lock-in (the AMI--though this seems to be opening up some), so it is also building its own "solar system". Have you seen [http://eucalyptus.cs.ucsb.edu/]?

Over time, I think we will see standards in "layers", such as at the IaaS, PaaS and SaaS levels. RPath will certainly make big money off of the layers it abstracts, but it should be content that money can be made at other layers without their involvement.

I've been working and deploying applications on the Web since 1994. I've gone from shared hosting on SGI boxes, to dedicated hosting, to co-location with Verio and Level3 (still have a couple racks full of equipment running there). I've decided to launch my latest Web/mobile app on AWS (Amazon Web Services), [http://ahTXT.com/ ahTXT.com (eBay auction monitoring and wireless alerts)] because of this primary reason: I no longer wish to manage hardware.

Amazon's EC2 is fantsatic.. even their smallest instance class is a high-performance server. However, all fancy-fluff and buzz-terms aside, EC2, at the end of the day, is just a virtual server. Your instance is just a Xen image. This means that at the end of the day, unless you implement some type of management solution (or outsource this to a management provider), you're dealing with a virtual server -- pretty much just like every other dime-a-dozen virtual server providers out there.

The benefit is the fact that you're running on enterprise-class equipment from top-to-bottom. That includes the servers, network switches, routers, probably even down to the quality of the cables. That also includes power redundancy/failover, environmental control (cooling/humidity), and so on. You don't quite get that with your run-of-the-mill $19.99/month "VPS" (virtual private server).

Again, my impetus behind using AWS was that I no longer wanted to manage hardware. But there are other important reasons, too. For starters, you cannot rely on cheap VPS for mission-critical applications. Secondly, you only pay for what you eat.. so if you want to launch 7 more instances and are clever enough to software load-balance between then, you can do that during a peak transaction period.. then kill the extra instances, and stop paying (you pay by the hour).

Okay, enough about AWS..

I watched the campfire presentation of Google App Engine and was initially excited. They took it a step further by taking away the need to launch additional instances and manage a cluster to load-balance, etc. I love the thought of building an app that gets slammed with billions of daily transactions and would not break, or even bend, for that matter.

But indeed, the thought of being locked into an architecture for a real business is kind of scary. I know, for instance, that if Amazon's service level started to fall, I could simply take my app back to the co-lo and load balance it across physical servers, and do it quite well. However, if Google ever decided to can my app, or demand more money than I could afford to pay to keep my app alive on their architecture, I'd have to re-write the software to be more like my traditional apps that run Apache/Tomcat on Linux, etc. and not the magical kingdom of Google and its AppEngine.

You know, there are third-party providers out there that are built on the AWS EC2/S3 architecture, and deliver the same promise -- "build your app, and we'll handle everything else." (scale, load, instances/servers, storage, etc.) If you're waiting around for Google to re-tool AppEngine for your development platform (PHP, Perl, Ruby, etc.), you may just want to check out these managed service providers on the AWS platform.

I agree in principle, but IMHO your argument is somewhat myopic. It's certainly clear why, as CEO of rPath, AppEngine is a walled garden to you. However, to be fair, I'm sure F5 or Checkpoint would see AWS as equally closed. As would many other vendors who's products don't fit easily into Amazon's unique AMI and storage model.

A more wholistic view of cloud computing is needed that allows for simple specification of requirements and interfaces so users can build applications and services that span the cloud.

I am in agreement here. I was excited to see Google jump in offering a computing infrastructure for their users, but I was disappointed that we could not use more than python. We have been using Amazon Web Services for 2 years for DigitalChalk and I was hoping to see some interesting alternatives pop up from Google. I think Google does have the right idea of handing scale transparently for the user. This is a great plus and a move that is welcomed but I would like to see other languages such as PHP and Java supported.