The launch of a billing system for its Web application hosting platform puts Google in competition with Amazon Web Services and Microsoft's Azure Services Platform.
Google on Tuesday plans to introduce a billing system for usage of its Web application platform, Google App Engine, a move that reaffirms the company's commitment to make a business out of Web application hosting.
In so doing, Google begins competing more directly with Amazon Web Services, which pioneered pay-by-the-drink computing, and Microsoft's forthcoming Azure Services Platform.
Previously, Google App Engine developers faced quotas for bandwidth, CPU time, and API calls. As of Tuesday, they can pay to play, should their applications see a surge in usage.
Google has been promising as much since last May, when it opened App Engine to any interested developer. The company also published a preview of its pricing plan in December.
In conjunction with the introduction of the new pricing scheme, Google plans to reduce its free quotas, though it maintains that App Engine apps still will be able to serve 5 million page views per month without charge.
The new rates are as follows: 10 cents per CPU core hour; 10 cents per gigabyte of traffic in; 12 cents per gigabyte of traffic out; 15 cents per gigabyte of data stored per month; and $1 per 10,000 e-mails sent. Google expects to officially announce the rates around 1 p.m. PST on its App Engine blog.
As a point of comparison, Amazon Web Services Simple Storage Service (S3) charges: 15 cents per gigabyte stored, up to the first 50 TB of data; 10 cents per gigabyte of data transferred in; and 17 cents per gigabyte of data transferred out for the first 10 TB.
But as Google App Engine product manager Pete Koomen points out, App Engine isn't directly comparable to Amazon Web Services. "App Engine has taken a different route," he said in a phone interview. "We're not offering bare virtualized machine instances. We're offering a framework that's a lot higher in the stack."
That ability to operate at a higher level has both advantages and disadvantages. On the plus side, developers should be able to develop apps quickly using App Engine because Google handles more of the low-level issues.
As Jerry St. Sauver, front-end developer for Giftag, puts it in a video extolling the virtues of App Engine, "A lot of the work that none of us really want to do is done for us."
Dave Westwood, the developer behind the popular BuddyPoke application, said much the same in an e-mail. He explained that Google App Engine is cost effective and allows social app developers to deploy without a lot of up-front investment. App Engine also makes scaling easy, he said.
Scalability, he said, is "a problem we don't want to have to solve. We're two guys, with a background in 3-D. The last thing we want to learn is how to scale. We're in the business of making social apps. We're happy to let Google take care of the scaling for us."
On the minus side, App Engine may not be as flexible as Amazon Web Services.
For example, App Engine doesn't yet handle offline processing. Applications receive a request and send back the results. You can't use it yet to write a Web-crawling application, though Koomen insists Google is working on that.
While Google can point to plenty of developers using App Engine -- there are 45,000 apps running on App Engine, Koomen claimed, generating more than 100 million page views per day -- it doesn't yet serve the sort of high-profile companies and Web operations that make their home on Amazon Web Services. That's likely to change, however, as the introduction of the pricing model underscores Google's intent to grow its platform into a mature computing infrastructure service business.
Want to hear more about security and cloud computing? Internet Evolution is hosting a Webcast on this topic on March 5. Find out more (registration required).
IT Service Management Must EvolveThe idea of technology being delivered as a service appeals to the 409 IT pros responding to our Service-Oriented IT Survey. But cloud providers are competing for that work, and CIOs are being selective.
In this special, sponsored radio episode we’ll look at some terms around converged infrastructures and talk about how they’ve been applied in the past. Then we’ll turn to the present to see what’s changing.