I’ll be the first to admit that I do not have extensive experience building large scale web applications that can handle millions of users. None of the services I have designed so far have grown to that level. Not many other people have personal experience dealing with this issue, and they’re not cheap either.

What I like about cloud computing services, if they can be made to look like a pretty standard LAMP server, is that you can focus on designing your application, and generally not worry about planning for unexpected success. Of course, if your app does take off and attract millions of people, you’ll be smart to hire someone who’s dealt with large scale services before, but if it doesn’t happen, you haven’t wasted time and money building something for people who never show up. Or if it takes off unexpectedly, at least your service does not completely fall on its face for several months while you sort through these issues.

It’s pretty clear that scalable services require deviations from the familiar programming models can can use for apps that run on a small number of machines. Pretending otherwise would likely create as many problems as it solves. Providing different interfaces helps set expectations up front: These services are similar to things you are used to, but they aren’t the same.

The young man’s mouth hung open for a full minute, and while he waffled, I sent him to http://danga.com for a copy of Fitzpatrick’s paper on avoiding write saturation.

Well, one thing the schema-less no join architecture buys us on top of Google’s GFS is no write saturation. So, a generation of table joiners and SQL jockeys will just have to get jiggly with a hierarchical or object based storage model.

Truth in the room, I would prefer not to compete with the richest company in the world, but, no one can advance a trend like they can. Many winners will exist when you think about millions of servers moving to the cloud in the coming decade.