Socks and Sandals

I was thinking about AppEngine some more today and it occurred to me that not only could AppEngine be responsible for a lot of people learning/using Python, but it very well might be Python’s answer to Rails. Its so-called “killer app”, if you will.

Up until this point, Python has been plagued with multiple, competing Web frameworks all taking some mindshare and there really hasn’t been a strong rallying point in the Python Web community like Rails. It appears that Django has been winning out in the blogosphere lately, but its nothing like Rails’ devout following in Ruby-land.

However, with AppEngine, Google does Rails one better: instead of just making it easy to code your app, they make it just as easy as Rails to code and dirt simple to deploy and reduce the operation maintenance to near zero. The need for things like ActiveRecord and migrations is pretty reduced in the AppEngine environment, as is all but a tiny knowledge of SQL (called GQL in that realm). That’s really, really attractive if you’re a Web consultancy shop that’s looking to turn over clients as fast as possible or a side project with a mandate for speed, quality and low cost. To me, that seems like it would be worth learning a little Python for.

AppEngine is pretty clearly aimed at Facebook’s F8 platform but it could end up hitting Python with a major boost in popularity as an aside. I bet Guido is smiling all the way to the bank on this one…

I just read a little bit about the recent announcement of Google AppEngine and I think its a pretty good service overall for certain kinds of Web applications. Unlike the rumors that were floating about prior to its announcement, its not a competitor to AWS directly, nor even a competitor to Ning as some have also claimed. To me, it seems more directly in competition with Heroku if such a thing could even be said. It is clearly based on Bigtable, though, so that part of the rumor appears to have been true.

Being so simple has some advantages and presents some interesting constraints. Because you don’t have root and can’t run the “box” yourself, you’re forced to think simply about the app itself. This seems as if it would be quite a welcome constraint for a lot of Web developers who don’t care about running a network. But the constraint really serves to enable Google-style scalability at its heart. As well, the use of CGI allows Google to run your code wherever they deem it best at the moment underneath, without you having to care about that sort of thing. This is something they already do quite well.

As well, the lack of a traditional RDBMS is something that obviously works well in a shared-nothing environment and makes a lot of sense since Google’s infrastructure is already based on such. This gives real credence to the idea that the RDBMS isn’t the be-all-end-all and will introduce a lot of developers out there to this new way of thinking.

A few things I don’t like:

• Users of an AppEngine app must login with Google Accounts
• You do have to upload your Python source to Google and this leads to obvious privacy and IP concerns
• No recurring job scheduling (essential for lots of different kinds of apps)

One more obvious thing is that an application built on AppEngine is one that is much, much easier for Google to acquire than one that is not. Don’t underestimate that piece of it, as its likely this service will be a loss-leader for Google.

Finally, I think this announcement will be very good for Python. As AppEngine only supports Python right now and for the foreseeable future, anyone interested in AppEngine will have to learn some Python. This will shed some more light on Python for people who might not have otherwise given it a try.

UPDATE: Apparently, others agree about the acquisition potential of apps on AppEngine. Good stuff.

Wow, this year’s ETE was even better than last year. A bigger crowd, a better venue and great speakers made this year the best yet. I can’t wait for next years! There’s a lot of cool stuff going on around the Philly area that you’d never know if it weren’t for events like this. E.g. did you know MapQuest is located in Lancaster, PA? I had no idea until yesterday.

In other conference news, my talk yesterday went pretty well. People seemed to really enjoy it and the room was full. You can view my talk slides on Hadoop on my talks page along with my other slides from previous talks (including last year’s ETE talk on Comet).

Thanks to Chariot for putting on another excellent event, in particular Tracey Welson-Rossman and her merry band of awesome facilitators! Keep it going for next year :)

Today a real validation for the Hadoop effort came in the form of Yahoo! announcing that their production search is now running on Hadoop. This should go a long way to allaying others’ concerns about Hadoop’s speed, stability or scalability. Cheers, Yahoo!: You’ve done some excellent work!

A couple hours ago I moved this blog, my main website and the PhillyLambda homepage over to the Slicehost service. I’ve been a Dreamhost customer since 2002 and back then they were great and cheap. They were great for a while after that, and then they were OK but now they are pretty bad. Routinely, when I SSH into Dreamhost, I see load averages in the double digits (one time it was 135+). Every time I post to this blog, I have to hit Publish and then hit back about 5 times to get it to really commit because the FastCGI keeps snapping between Apache and Rails and throwing up a 500 error. I was getting pretty tired of it all.

So, for just a little bit more money I get my own dedicated VPS where I can run whatever I want. I’d heard really good things about Slicehost for a while so I decided that when I got the time, I’d move my sites over there. I also am using DNS services from Nettica as they were very good to me while I was at Commerce360. Here’s hoping that when I press Publish this time it just does it! ;)