The often deranged postings of yet another hacker, pretending to be an Astronomer, pretending to be a hacker who has written a book or two for O'Reilly Media.
Showing posts with label Google App Engine. Show all posts
Showing posts with label Google App Engine. Show all posts
Want to manage your Google App Engine applications from your iPhone? There's an app for that...
The App Engine Manger application allows you to to monitor the status of Google App Engine in real time, estimate your monthly costs based on your current usage levels, then lets you estimate how much a sudden usage spike could cost.
It also allows you to look at the performance of each of your applications individually and examine requests per second, upload and download bandwidth and CPU.
It was a long walk between the keynote room, dubbed Space Invaders, and the App Engine talk here in Donkey Kong, and Google has set up a number of feeding stations along the way for weary developers...
Mano Marks talking about App Engine
But I'm now in "A Deeper Look at Google App Engine" given by Mano Marks.
We've got the first estimate so how much App Engine is going to cost above and beyond the amount Google is giving away for free, about US$40 if you use double the amount of traffic in your preview allocation. There is also support for cron'd jobs, SSL and other languages, apart from Python and presumably the already semi-public effort to port Perl to App Engine, coming soon.
After a brief discussion about what Mano can't talk about, mostly when new languages are coming to App Engine and what those languages will be, we've dived directly into the code, and we're looking through the example that will be used in the App Engine code lab this afternoon. Which I still haven't decided whether I'll go to yet...
We're talking about Bigtable, the storage mechanism underlying App Engine, and Mano is really trying to emphasize that it's not a relational database, it's an object orientated (schema-less) database.
After running through request handlers and entities, we're now talking about counters. One major difference between relational database and a distributed datastore like Bigtable. Bigtable doesn't know counts by design, must scan every entity row. Google is encouraging developers to create a separate entity that you can increment every time a entity is inserted, and decremented every time one is removed. However if you're doing frequent updates you'll end up with a requests queuing up to update the counter. The solution is to use a sharded counter. You create a number of shards, and when you go to increment the counter you pick a entity at random. Mano is now running through how this works in practice...
Mano is showing an implementation of sharded counters using Bigtable and memcache, I'm wondering why this isn't available as a default Google library so is just becomes the way counters are done with Bigtable..?
...and we're out of slides, opening the floor to questions the first one is exactly that. Why aren't counters built into Bigtable? The answer is, "good question". They're trying to keep the environment as clean a Python environment as possible, but I'm not entirely convinced that answers the question?
Interestingly, the recommended work around for the lack of cron support is to set up a remote call that polls a known end point inside App Engine periodically. However you need to remember that every job on App Engine only has 10 seconds to run, and is killed after that time limit is reached, so if you're trying to do something periodically that might take a lot of time to complete (for instance re-indexing) you might have to split this request up into chunks.
Over the last couple of weeks there have been rumours running around that Google would be launching something to directly compete with Amazon's AWS suite, and embed themselves even further into the Cloud. Sure enough, while I was asleep, Google announced a preview release of Google App Engine at Campfire One.
But what Google has done is take a totally different approach to Amazon. The Google App Engine is basically a platform for producing and deploying (robust and scalable) webservices, where as Amazon's offering is a more pick and mix affair with storage (S3) and compute (EC2) and databases (SimpleDB) being offered as components rather than being integrated into a single platform.
However, one of the reasons why Amazon's S3 storage service has taken off so rapidly is the fact that it can be viewed as a component, and startups (and much larger firms) can use it transparently. So long as you wrap the service sensibly, if Amazon went bust tomorrow (unlikely) or the service became unavailable or unreliable (slightly more likely, but still unlikely) you wouldn't have to rewrite your entire code base. You buy a whole bunch of servers, assuming you can afford it, rewrite the low level library that handles storage, and you're set. You still maintain control.
Google isn't offering as much control as Amazon, if you build your business on Google's platform you're relying on Google to support your business. It's an interesting choice from Google's point of view, and it'll be interesting to see whether people will bet on Google. It looks like a sure bet, but if I was investing a lot of money into a business I must admit that it would probably make me rather nervous to leave so much control in the hands of another company who of course have their own objectives.
It seems very clear that, unlike Amazon's EC2, the App Engine doesn't have the potential (at least in its current incarnation) to be a general computing platform, it seems to be specifically built to be request driven, and that's okay.
Google's choice of Python as its runtime is probably fairly predictable, when you work for Google you have to use one of the four allowed languages, at least for deployable code, those being C++, Java, Python or JavaScript. Of the four Python is the obvious choice...
While I'm not a Python person, my language of choice to get things done is Perl, due to circumstance I've actually had to write a bunch of Python before. So while I'm not a guru, I can get things done in Python, abet slowly, all the while muttering that I'd get it done faster if I was writing in Perl. So I've put myself into the wait list for a slot in the preview release. I'll let you know if get accepted before they open the doors properly, I guess it'll take a while though...
However the release of Google's App Engine does mean that I'm even more annoyed than I already was, which was fairly, that my travel budget won't quite stretch to a trip out to San Francisco for Google I/O. I've already had to shelf plans to head out for Where 2.0 due to the budget squeeze here in the UK, although since I've already been out to ETech this year and will be heading to OSCON in July maybe I shouldn't complain? My a Dopplr trips list is still looking fairly full after all...
I'd have loved to have seen Larry Wall doing one of his typical off the wall talks at the launch of Google App Engine with a Perl run time. But I guess you can't have everything...
Update: Show your support for Perl as the next language runtime to be added to the App Engine. Right now (10/Apr) this is the second most highly ranked support request, just behind support for urllib and urllib2 interfaces in Python. Surely we can do better than that?
