Feeds

Google rejigs new dev cloud prices after coder outcry

Concurrent Python on way to App Engine

Beginner's guide to SSL certificates

One week after introducing a new pricing structure for its App Engine development cloud, Google has announced a handful of changes to the setup in response to complaints from many of the developers currently using the service.

App Engine is an online service that lets you run applications atop Google's famously distributed infrastructure, and it has been in "preview mode" for the last three years. The new pricing structure won't take effect until later this year, when the preview tag comes off, but Google announced the overhaul last week at its annual developer conference so that existing users had time to prepare. Among other things, Google plans to charge according to how long a virtual instance runs rather than charge for CPU time.

"Due to customer feedback and to better service memory-intensive applications, we will be eliminating CPU hours," the company said. "Instead, our serving infrastructure will charge for the number of Instances running as a new unit called 'Instance-hours (IH)'." An instance hour is, yes, one instance running for one hour.

Many users complained that the switch would make it impossible to run certain applications on the service, though in speaking with The Reg some acknowledged that they wouldn't be able to gauge the full impact of the changes until they were actually rolled out.

"They've changed the whole pricing model, and there's a bunch of uncertainties in there," App Engine user Jeff Schnitzer told The Register after the new pricing model was revealed. "Basically, what they announced was: 'Pricing is going to change, but we really have no idea how much it's going to change'. I'm trying to withhold judgment until they get everything nailed down."

Schnitzer was adamant, however, that the new model would have an adverse effect on developers who were running Python applications that handle myriad concurrent requests. At the moment, Python instances running on App Engine cannot be multithreaded. "If you have Python instances that are making call to external servers, to, say, Facebook, which is very slow to respond," he said, "you're going to end up with a lot of instances, because each instance can only handle one request at a time."

But on Tuesday evening, a week after announcing the new pricing structure, Google's Gregory D'alesandre posted an FAQ to the App Engine mailing list, seeking to better explain the new model and announce a few changes to the model. He said that the company would continue to take feedback on the new model, and indicated that additional changes may be made. D'alesandre's FAQ and his changes to the pricing model have not yet been added to the App Engine website.

"This FAQ is intended to help answer some of the frequently asked questions about the new model," he said on the mailing list. "We are interested in hearing additional thoughts and comments you have based on this. Once it is relatively stable I'll add it to our official docs."

In his email, D'alesandre said Google is currently working to add concurrency to Python on App Engine. This will arrive, he said, with the Python App Engine release 2.7, and before its release Google will provide half-priced Python instances. "We’ve heard a lot of feedback from our Python users who are worried that the incentive is to move to Java because of its support for concurrent requests, so we’ve made a change to the new pricing to account for that," he said.

Last week, Google said that in addition to usage fees, it would change a $9 per app per month fee for all paid applications on the service (you can also run free apps if you're under certain usage quotas). But in his email, D'alesandre said that this $9 fee will be changed to a minimum payment. "Based on the feedback we’ve received we are changing this $9 fee to be a minimum spend rather than a fee a originally listed. In other words you will still have to spend $9/month in order to scale but you won’t pay an additional $9 for your first $9 worth of usage each month."

Google will still offer what it calls Premier Accounts, which will allow users to run as many paid apps as they like for a $500 per month fee, plus usage fees. This fee will stay at $500 per month because it also covers operational support.

In his FAQ, D'alesandre indicated that Google had switched from CPU-hour pricing to instance-hour pricing because CPU time accounts for only a portion of the resources used by App Engine. "When App Engine runs your code it creates an Instance. This is a maximum amount of CPU and Memory that can be used for running a set of your code," the FAQ read. "Even if the CPU is not currently working due to waiting for responses, the instance is still resident and considered 'in use' so, essentially, it still costs Google money.

"Under the current model, apps that have high latency (or in other words stay resident for long periods of time without doing anything) are not able to scale because it would be cost-prohibitive to Google. So, this change is designed to allow developers to run any sort of application they would like but pay for all of the resources that are being used." ®

Top 5 reasons to deploy VMware with Tegile

More from The Register

next story
IT crisis looming: 'What if AWS goes pop, runs out of cash?'
Public IaaS... something's gotta give - and it may be AWS
Linux? Bah! Red Hat has its eye on the CLOUD – and it wants to own it
CEO says it will be 'undisputed leader' in enterprise cloud tech
Oracle SHELLSHOCKER - data titan lists unpatchables
Database kingpin lists 32 products that can't be patched (yet) as GNU fixes second vuln
Ello? ello? ello?: Facebook challenger in DDoS KNOCKOUT
Gets back up again after half an hour though
Hey, what's a STORAGE company doing working on Internet-of-Cars?
Boo - it's not a terabyte car, it's just predictive maintenance and that
Troll hunter Rackspace turns Rotatable's bizarro patent to stone
News of the Weird: Screen-rotating technology declared unpatentable
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
Intelligent flash storage arrays
Tegile Intelligent Storage Arrays with IntelliFlash helps IT boost storage utilization and effciency while delivering unmatched storage savings and performance.
Beginner's guide to SSL certificates
De-mystify the technology involved and give you the information you need to make the best decision when considering your online security options.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Secure remote control for conventional and virtual desktops
Balancing user privacy and privileged access, in accordance with compliance frameworks and legislation. Evaluating any potential remote control choice.