> root / 2011 / September / 12th

DayNotes, otherwise known as a 'blogpost' I believe.

Outside the Guardian at Kings Place

So today has been mainly organising Google AppEngine Applications. As anyone who's dealing with AppEngine is aware the billing method is changing... and slightly radically at that.

Before the change we were getting charged for CPU usage per hour, incoming and outgoing bandwidth, storage and so on. Which was great as you could just create a new App to do something trivial and not worry about it too much. There was also this great philosophy behind it, which was roughly... build something and we'll scale it for you... even it it gets slashdotted or whatever we'll scale up to meet the demand, worry about backend infrastructure no more!

From a coding point of view this is great, I don't need to worry about what's actually running the code, it's all "cloudy". I do have to worry about how I code my app as some tasks "cost" more CPU cycles than others.

A general rule of thumb was; if it serves the data faster, the CPU cost is greater, so a database hit 'costs' less CPUs but took longer to serve up the results to the end user. A memcache hit served up the data faster, but cost more CPU cycles. You could end up in the weird situation of a page serving in 500ms but the CPU cost used to deliver that page could be in the order of 2500ms.

You were basically picking a point somewhere between serving fast or costing less. For applications that poll for information and sometimes do something with the result, serving quickly wasn't much of a problem and therefore even easier to keep the price down. I'm mainly thinking Twitter Bots here.

Now it's all changed, the change makes sense but rather goes away from the original core philosophy. We're now charged for "instance hours", it goes somewhat like this...

If a request comes in, an "instance" is spun up to service that request, the instance will that stick around for 15 minutes ready to serve any new requests. The act of spinning up an instance takes some so having it ready and waiting is theoretically good.

The down side is if you have a task that runs once every 10 minutes to check something, that instance stays alive forever, it never has a chance to die.

In one case I'm actually running an instance 24/7 for a total of 4.6mins CPU time.

I understand what they're doing and it makes sense, but at the same time I'm now no-longer care-free of how my app works and happy just to let Google scale it, I'm now managing 'instances'. Even though that 'instance' may be spread over several CPUs in various locations, meaning I don't have to worry about maintaining a specific box. I am now thinking in terms of running my code on x number of servers, which is totally what I didn't want to be thinking about.

If I wanted to be in that mindset I could rent a server, or use one or more Amazon EC2 instances. This, AppEngine, wasn't supposed to be that.


I have several trivial AppEngine Apps running along quite happily, each using up a small handful of CPU cycles, but each keeping a whole 'instance' alive. The answer seems to be to put them all into one singlemeta App with a small amount of management, allowing them to all run off one 'instance' rather than several.

It's not the end of the world and I'm certainly not as much up in arms about it as some others. But it is a shame to be thinking in terms of 'boxes' and 'instances' rather than just CPU cycles, bandwidth and DB reads/writes and I think AppEngine has lost some of its charm for that.


There are some technical problems with the new Billing though. Above I talked about a single instance staying alive to serve any request… having an instance alive makes perfect sense and indeed the new billing model allows you to have 24 hours of instance running for free, you only pay for more than one instance.

Which sounds (more than) fair, keep everything running on just one box and then it's free.

However, AppEngine feels free to spin up extra idle instances if it thinks you're going to need them, if left to its own devices it'll spin up several instances and keep them there. You don't get charged for any that stay idle for over 15 minutes, Google just hasn't got round to killing them yet. But you do get charged for the first 15mins that it's there just-in-case it gets used.

On an App by App basis you can tell it how many idle instances (idle instances are the number above the 'main' instance) you want, in this case the lowest number is 1. But I've ended up with my main instance up and running for 24 hours and then Google firing up the extra now and then, causing me to use 27 hours of instance time in a 24 hours window, even though the main instances had more than enough capacity to handle the minimal requests.

So no matter how careful I am in writing my application, Google can just fire up an extra instance for no accountable reason and then charge be for it :/

## Table of Contents: September

### More

### About

This is what used to be a blog, but is now an online diary/archive sort of thing. As I'm laying off the twitter a bit and currently reclaiming all my Flickr photos this is the main place to find me, (subscribing via RSS) should still work.

I also have a podcast, with more audio experiments on SoundCloud. A smaller "scrapblog" is over on tumblr. If you need to get hold of me email hello@revdancatt.com

### Blogroll

Other blogs I track, some on the offchance they start publishing again.