Yousef Ourabi [04.14.08 03:30 PM]

Porting the python/wsgi bit (framework and all) is the easy part --

Getting the data that is already in Big-Table out, and migrating away is *not* especially when there is a 10 second time out on any script that runs on GAE...

That is lock. All code is throw away-code anyway -- the Data is not, and that's what is in BigTable and that's what YOUR not (currently) able to migrate away.

  Niraj J [04.14.08 05:11 PM]

Reminds me of the attempts people made to port COM/DCOM to unix.

The problem is not being able to run your app in a different infrastructure. The problem is the "Programming Model" you have to adapt.

  Scott Lawton (Blogcosm) [04.14.08 05:13 PM]

If you're worried about the data, just write it to 2 places. Or have a cron job running on another machine that fetches new stuff every night by making HTTP calls. Efficient? No. But that's one of many workable solutions.

Google App Engine is an interesting and useful alternative, will get better over time, and will help encourage the competition to step up.

  Charlie [04.15.08 02:13 AM]

As expected, Google has already said they're going to provide full batch import/export soon. And they've said that batch processing jobs are on their short list.

What I would really like to see is OpenID support, rather than Google account lockin. That could be uploaded by a developer but it would be nice to have it as a service provided by app engine.

After all, if you use their Google Accounts service, your users are all signing in with their Google Accounts. If you want to switch platforms, wouldn't that be the thing locking you in? You can't take Google's authentication system with you when you leave the GoogleCloud... can you?

(and even if you can, OpenID is still the less evil way to go about it)

  friarminor [04.15.08 02:24 AM]

Workable solutions will multiply not limiting as we expect more to enter the cloud compute space. At present, there are several PaaS player albeit small like Morph eXchange that does manage the whole Rails apps deploy process.

It all is getting options really if you don't get yourself sucked in a 'cattle' herd mentality.

Best.
alain

  Cliff Hall [04.15.08 09:18 AM]

Another way to mitigate 'lock-in' is to take steps in your software's design that anticipate a migration to some other platform in the future.

Good rules of thumb to actually put this into practice are to rely on proven design patterns and idioms that do not rely heavily on any platform-specific magic.

If you get the actors and their roles, responsibilities and collaborations right, an implementation should migrate easily to a new platform.

The PureMVC framework was built with these ideas in mind, and now a framework that was originally intended for ActionScript 3 (Adobe Flex, Flash and AIR) is now fully supporting development in Python and a greate way to write your Google App Engine applications.

Check out this PureMVC / Python / Google App Engine demo: http://puremvc.org/content/view/65/1/

You'll also see a demo that was ported from a Flex browser based app to wxPython on the Windows or Mac desktop.

The relevance of this is that PureMVC defines a clear and simple methodology that enables you to write apps that can more easily be ported to other platforms. Thus it will ease your eventual migration when the platform your apps are all written for become 'so last millenium'.

-=Cliff>

  Steve Bjorg [04.15.08 12:38 PM]

This is missing the point. The whole idea of App Engine is that it complements EC2. See blog post about Cloud Software here: http://is.gd/5wY

  Andrew Trossman [04.15.08 08:55 PM]

Initially I too thought AppEngine was trying to lock developers into their APIs/services. However, Reuven from enomalism explained to me how those apis could be easily replicated on top of other infrastructure such as EC2 and couchdb or hadoop hbase (instead of bigtable). The very next day I see someone's implemented at least the first part of this with AppDrop ;-) Although, it looks severely crippled as a single instance of the sdk. I think Reuven had ideas of using enomalism (also open source) to automate a scalable implementation - love to see it!