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.)
The easiest way to use Cloud Foundry is to create a Spring project from a template with SpringSource's customized version of Eclipse called the SpringSource Tool Suite. I tried installing some of SpringSource's tools into my own version of Eclipse, but the right collection of libraries was not easy to find. The SpringSource Tool Suite is simpler.
The Cloud Foundry is not limited to Spring. There's support for Rails, Sinatra, Scala, Grails, and Node.js. It's all running on the JVM even if you don't write any Java. Cloud Foundry just announced PHP and Python/Django support as well. The VM image that you get also comes ready with MySQL, MongoDB, and Redis databases waiting to suck up your information.
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
It's all about knowing how to build an open source community -- plus experience running applications in...
Win7 Update scans got you fuming? Here’s how to make the most of Microsoft’s 'magic' speed-up patch
Sponsored by Hewlett Packard Enterprise
The proliferation of insecure devices in every facet of our lives will have consequences far beyond the...
From a simple platform for beginners to an expert-level development workbench, there's an IDE for most...
You don't need to buy a new phone to add hours to your battery. All you need is to flip a few switches...
Look to these clever open source tools to keep secrets out of source code, identify malicious files,...