The low-rent, master-slave configuration is supposed to be about one-third the cost of the "high replication" version, with each low-rent write costing about five-eighths of the high-rent equivalent. The low-rent version may be twice as slow on writes as the high replication cloud; then again, it might not. You have to be careful with some of these numbers because the mechanism includes lots of hidden overhead. Each name-value pair, for instance, includes all the names as overhead because there's no schema. That's the price you pay for the flexibility to store any old thing in any old row.
For some reason, I found myself fretting about the lack of access to the file system. I realize that the idea is to store the bits as blobs so that App Engine can optimize everything, but I still like the ability to write to the file system for some projects.
One of the biggest changes in App Engine is the appearance of economic reality. While Google heavily subsidized the first crop of applications by offering so much for free, it has slowly been squeezing the free apps and pushing people to pay for what they get. Free apps can now access the data store 50,000 times a day -- which adds up quickly if you keep more than a few items in the data store.
The new price list includes a long set of quotas and rates. All seem tiny and reasonable, but I have no easy way to compare them. Is 1 cent per 10,000 reads from the data store a good price? Should I hold out for 1 cent per 12,000 reads? Somehow it seems easier to go to the boss and ask for a box with two quad-core processors, a ton of RAM, and some fast disks, then cross our fingers. It's not very scientific, but it's so much easier than thinking through all of the details.
One interesting detail is that the App Engine sort of strips away your ability to tune your application's performance to handle peaks: 100 emails will always cost one penny. You can't save money with a cheaper processor and a queue that delays the email.
Java clouds: Cloud Foundry Spring has always been one of the cleanest frameworks in the Java enterprise world. It makes sense that someone would use it as the foundation for a Java cloud. That someone in this case is SpringSource, one of the Cloud Foundry project leaders and a division of VMware. It should come as no surprise that this cloud is built on top of VMware virtual machines.
(The VMware-hosted Cloud Foundry is a bit of a departure from past offers. The first version deployed Spring apps to the Amazon EC2 cloud. It's still available from classic.cloudfoundry.com if that's what you want.)