Google App Engine Gets Perl, Sort Of

If you are not familiar with it, Google App Engine is Google's entry in the cloud, specifically a PaaS or Platform as a Service. With the Google App Engine, you get an IDE (python) to code your applications and then you deploy it to the Google cloud. You can integrate with other google services (as well as other http services) and use BigTable as a data store.

One of the limitation, IMHO, of Google App Engine is that it limited to Python. While I can do a little bit of python coding when I have to, I'm not a big fan of it. I don't see anything wrong with it, I just only have so many hours in the day and getting deep into python is not a priority for me. Having said that, I think I would rather python to Java.

What I would love to see is a truly pluggable architecture where a developer can choose his own language to interface with the app engine. Obviously, core code would need to be in the language of Google's choice but everything else should be pluggable via services or APIs. That may be closer than I thought.

Brad Fitzpatrick announced on his blog that he is working on a 20% project to add Perl to google app engine. He makes sure to be very specific that he is not on the app engine team and that this is not an app engine effort:

To be clear: I'm not a member of the App Engine team and the App Engine team is not promising to add Perl support. They're just saying that I (along with other Perl hackers here at Google) are now allowed to work on this 20% project of ours out in the open where other Perl hackers can help us out, should you be so inclined.

This is also not quite what I would like in that it is an effort to add Perl, not open it up for pluggable languages. Of course, as Brad says, the need for a hardened interpreter does require internal google effort. Still, this is a nice start. I prefer Perl to python.

LewisC

Technorati : app, engine, google, perl, python

The Storage Cloud, Currently

InformationWeek has a good article, Behind The Storage Cloud. This article gives something of the plumbing behind the available storage in the cloud. Something they didn't talk about in that article are the limitations I have been running into using the cloud.

For infrastructure providers like Google or Force.com, who are offering a PaaS (Platform as a Service), the storage is built into the application. If you chose them to develop your application, that works out fine. However, if you are looking for archiving or storage scaling (grow storage as you need it), it's not so good.

Amazon offers a different kind of storage. S3 is a web based storage system. It's like a bucket for data. It's the biggest bucket you'll probably ever see, but it's just a big bucket. When you create a new directory, you're creating a smaller bucket in the big bucket. The namespace for the bucket is global. That means that your smaller bucket can't have the same name as someone else's bucket. That's a huge limitation.

Another issue with S3 is that it is a web service and not a block device. That means you can't directly attach it and use it as a file system. You need to make API calls. Even from within EC2 (Amazon's Cloud Computing Environment), S3 is only accessible through the API using PUT and GET style commands. Amazon is working on allowing EC2 to attach directly and there are other projects working on the same thing, PersistentFS being one of them.

I haven't found a good, cloud based attachable storage yet. I think Amazon, when they make S3 attachable will be the first (although that might only be attachable from within EC2). What is currently available is a plethora of archival solutions. For home usage, I don't think anything beats EMC Mozy. For $4.95/month, you get unlimited storage for one PC. It's slow to add new files (at least for me it is), but overall, I don't think any of its competitors really compete. I tried two others previously and decided to go with mozy for its price/feature ratio.

For business archival, I don't know that I would recommend Mozy. It's not that I would recommend against them, I just think there are better options. Off site, tape backups are still cheap and reliable. For the SMB market, burning a DVD once a week might even be enough. Just depends on your workflow and volume of data.

As a side note, it would be fairly easy to write a custom application to automatically backup changed files to S3. At less than 20 cents per month per GB, that might be a fairly reasonable solution, especially if you frequently need to access the archived data. I might even write a free giveaway to do just that. Just a POC kind of thing.

Technorati : amazon, cloud computing, cloud databases, ec2, force.com, google, mozy, persistetnFS, s3, storage