Infrequently Noted

I'm not sure who or how, but I got an invite to yesterday's Camp Fire One event at Google where they announced their new App Engine platform. The event itself was small-ish, with lots of interesting people invited (both from Google and not). I had no idea ahead of time what the announcement would be, and frankly I forgot all about the event until the day of. I'm glad I remembered (note to future self: next time, pack gloves and a hat).

As they started talking about the platform and what's part of it (and what's not), I couldn't escape escape the feeling that they'd gotten it right. It is absolutely the case that for most apps, scaling requires some amount of re-architecting. Systems like Rails are built with such a dependence (intentional or not) on the features of relational data stores that they quickly hit bottlenecks because frameworks aren't keeping developers out of the gutter. This is nearly the same lesson that the security community collectively came to when it started to beat the average developer about the head regarding the awesome power of defaults. What systems do and don't do for you "cheaply" defines their character, and in many systems those choices aren't made consciously, or if they are, they don't have the benefit of a different perspective which might de-emphasize certain traits. Call it libertarian paternalism, choice architecture, or pure condescension, but whatever it is, systems and platforms today are in the explicit business of making some things easier than others.

As the presenters showed how to make an app quickly, I knew I was looking at something I hadn't seen the likes of since Jot. We all know that Big Table is a column-oriented data-store, but since most people are still stuck on the likes of MySQL, it's hard to appreciate how liberating it is not having to think about how adding properties to models will affect a schema. The way App Engine is constructed lets the data store layer provide something called expando models. These models give us the kind of flexibility that I've only ever enjoyed before inside of Jot. Want a property? Just add it. No migration, no schema version...just data finding a happy home, and as your app's skeleton "solidifies" and you figure out which properties really do need to be faster, you can migrate that data into fixed properties with indexes and types and all that jazz. It's like a gradual type system, only for data stores. It's agility nirvana for application development.

Speaking of application development nirvana, they also had the good sense to start with a great language (Python) and a great webapp framework (Django) as the basis for the new system. For all the Rubyists and Java heads out there who are surely crying bloody murder, I suggest that they just try it. Seriously. Django's template system is freaking sweet, and Python (despite it's lambda-related warts) is close enough to being executable pseudo-code as to still hold the second place in my toolbox of languages.

There's a lot which I'm sure others will (and have) covered about how App Engine is going to change the game for startups and players like Amazon, but I think that if someone else had launched this system it would still survive on its merits alone. The only wrinkle in the whole thing will be seeing what's done about pricing over the long haul. It really shouldn't be hard for Google to beat S3 on price, and I'm sure there will still be a market for EC2 for non-traditional tasks, but fundamentally I think App Engine has all the makings of something really, truly better than the current (assumed) stack.

After more than a year of mourning the effective loss of Jot as a platform, writing apps on the server just got interesting for me again, and that may be the highest praise I can offer and framework or platform.