Although these three projects each take a different stab at the same problem, they all agree on one thing, “you should really put DB in your name…somewhere.”

Amazon SimpleDB solves the problem that a lot of EC2 explorers end up running into the minute they want to have persistent data across sessions. Because EC2 is a fresh slate on each reboot, typical databases aren’t really usable, unless you spend an awful lot of time figuring out how to off-load your data to Amazon S3 on a regular basis.

I wish I had some sort of pithy analysis of the recent leanings by web-visionaries away from SQL databases and towards these sort of REST db’s. The timeline in my head goes something like this:

Raw SQL begat ORMs begat full stack web frameworks begat wrapping a REST interface around an ORM begat “hey, let’s have our controllers talk to the REST interface, rather than the ORM” begat “hey, why do we need an ORM, or a traditional database? Let’s just make a REST accessible database!”

I guess that’s relatively pithy.

Really though, I’m not entirely sure what to make of this “trend.” I’ve yet to build even a trivial project using any of the three (Amazon is a closed beta, so I’m not sure if it’ll even be a possibility anytime soon). Maybe it’s time I take a crack at one of them.

It’s a great idea. Virtualization allowed me to work around a lot of rules as $last_job, and has the potential for easy deployment and at $new_job. Given the ease of use of a variety of virtualization options out there in the world, the idea of deploying your Rails / Django / Whatever app to a pre-built container is a really good one. It’s not a trivial exercise to get a nice LAMP stack approved by a stodgy sysadmin infrastructure. It’s way easier to say, “let me drop this vmware instance into your great big awesome vmware machine.”

Good idea Railsconf attendees. Attention everyone else: begin stealing this idea immediately.