Is AppEngine Python's Rails? 4
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…
Great post Toby!
Did you notice in the video of the announcement that when Guido said they would eventually support other languages and frameworks on AppEngine, someone shouted out “Ruby on Rails!” and Guido said “Sorry, I’ve never heard of it”. Haha, it will be interesting to see if/when the do support Ruby/RoR.
I think its extremely hilarious to watch all these yuppies run to Python and Google like its some all mighty powerful sentient being thats going to suddenly bring them wealth and absolute programming power.
Yeah Python’s great… its been great. There are so many things I enjoyed while writing Python… thats not the issue. The issue is just more plain old developer lock-in. First the kids ran to Facebook, then (briefly) Apple’s iPhone Dev kit, now its Google and AppEngine. Everyone wants to move onto the web, and it looks like technology dependence is here to stay.
How do you become the next Google by relying on Google infrastructure?
Justin:
I don’t think its so much about becoming the next Google, as that would obviously be pretty hard running on Google’s own infrastructure. Rather, the benefit of AppEngine in my eyes is that it reduces or eliminates the need for an ops department in a lot of places where its currently necessary.
The concerns about sharecropping are valid but if you have those concerns for your particular app there are many alternatives such as Amazon AWS, Joyent, TextDrive, AppNexus, etc.
Basically, I think it boils down to the fact that people don’t want to have to maintain clusters of machines. Without that, these services wouldn’t be getting the attention they are. Given that, the move is to just pick the one you feel the most comfortable with and has the best features and cost/benefit ratio for what you’re doing.
Toby:
Valid points which I can totally jive with… I’ve personally helped tear apart data centers and move them out to larger, third-party shops so I understand those changes taking place today. I hope one day to off load the projects I have to the likes of some of these companies. But thats kinda my other point.
If I want to move I can. It’ll be interesting to see how well you can move an app off Google’s services because with the iPhone OS and Facebook you sure can’t. Generally with Rails I can pull most of the Ruby out of the AR models and still have a working app in other Ruby frameworks and infrastructures.
Hopefully the people getting into AppEngine won’t take Google’s Authentication as an option. I also hope that doesn’t starve the spread of OpenID. I know Google is an OpenID provider, but lets see how long it takes them to become a consumer (generally easier to implement).