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.
You may still be better off sticking with Win7 or Win8.1, given the wide range of ongoing Win10...
Angular 3 will have better tooling and will generate less code; Google also is promising a new major...
With recurring and new problems in spades, Win10 Anniversary Update is still not ready for prime time
A convoluted user interface and crippled mobile features limit the conferencing tools' utility, but...
Google's co-founder admits he didn't pay attention to AI in the 1990s because he didn't think it would...
The challenge: AWS, Google, Microsoft, and IBM own the market, enterprises want to drop Oracle...
Ransomware has become the scourge of the internet 28 years after it first appeared. Here's how to...