
AppScale: an open-source version of Google AppEngine - chaostheory
http://code.google.com/p/appscale/
======
pierrefar
From the home page: "AppScale is supported by Google and the National Science
Foundation". Google? Wow.

~~~
DocSavage
The App Engine team has been very cognizant of the lock-in issue and how it
may prevent developers from using App Engine as a platform. When asked about
this, they usually mention (1) this project at UCSB, (2) using Django as some
abstraction level, and (3) being aware of your SDK API use. Method #3 means
the team pushes standard ways of interfacing with Google services like GData
instead of rolling out App Engine-specific APIs that won't be as portable.

~~~
pierrefar
All good stuff. I think the best option IMHO is a drop-in replacement for
AppEngine. This way a service can start easily on AppEngine and when it's big
enough, can roll out on its own infrastructure.

Interestingly... this is the same play MS used to gain prominence: they
controlled the API and the more code was written for it, the network effects
kicked in with more force. Very interesting parallels here.

------
sachinag
Could you theoretically take AppScale and Eucalyptus and create your own cloud
startup?

~~~
codeslinger
No, because, theoretically, anyone could and several will.

------
codeslinger
I'm confused: given the quota problems and serious constraints of the real App
Engine, why would I want a clone of it that I also have to maintain and manage
myself? Isn't the value-add here that I get SysOps and all that for free with
GAE? Isn't the cost-savings of GAE coming from its scale, and if so, how could
a private AppScale cloud running on Eucalyptus or similar garner the economies
of scale to make it cheap enough to be viable? As well, don't you have to have
the expectation of servicing a large number of applications of the type that
work with GAE to even consider something like this? (something that a
typically enterprise is not going to need)

In short, I'm really confused as to what the big deal is. Can someone
elaborate on the above questions?

~~~
gojomo
If you fear being trapped sharecropping on Google's land -- that they might
arbitrarily change the GAE rules, or prices, or capabilities, or even cancel
the service entirely -- this gives you the possibility to migrate elsewhere.

Migrating elsewhere might not be better along any single dimension (price,
speed, reliability, etc.) at any particular point in time. You might never
need to do it. But having the option is gigantic. It makes GAE a much, much,
safer platform on which to develop. In a pinch, you could port elsewhere in
short order without reengineering your service architecture.

This is a very impressive move by Google. It removes my number one fear of
using GAE. I'll be watching AppScale closely.

~~~
babyshake
"they might arbitrarily change the GAE rules, or prices, or capabilities, or
even cancel the service entirely"

The risk of Google doing something to simply enrage GAE developers is very,
very low. Is there any non-hypothetical reason why they would do this?

~~~
gojomo
Google has killed a bunch of unprofitable projects recently. Lively died with
6 weeks' warning, and users who wanted to save their 3D handiwork were told to
do so by "taking videos and screenshots of your rooms". I don't blame Google
-- they don't owe anyone continued development of a money-losing business line
-- but it happens.

And that's with Google still making barrels of money and not yet facing
significant antitrust action for using profits from search to underprice
products in other markets (like cloud services). With a few unprofitable
quarters or lawsuits, what's the guarantee GAE will continue in an attractive
form indefinitely? What if they decide they have to maximize revenue from
developers locked-into the GAE platform? (Or what if the core team leaves to
do their own startup?)

Even a tiny risk that another company could yank your platform out from under
you on short notice, for arbitrary reasons having to do with their business
needs (and not yours), may be unacceptable. AppScale mitigates that risk -- a
lot.

------
jwilliams
Interesting. Their homepage is here:<http://appscale.cs.ucsb.edu/> \--
Apparently they are supported by grants from Google and the NSF.

------
jaaron
Those interested in this might also want to check out Babble:

<http://www.babbleapp.org/>

It was created by 10gen as an AppEngine competitor and it's now released under
an open source license.

------
blasdel
This is awesome, it's one more burden off the AppEngine team's shoulders. When
I talked to them 6months ago, they pointed at 'AppDrop' as their answer to
this, and I could see the disingenuity in their eyes. Some dude spent a couple
hours doing that, and probably spent more time writing the blog post than
working on it.

Now they have a substantial option. I was surprised to see HyperTable support
-- it's a solid piece of work, and plays to my biases a lot better than HBase.

------
bprater
Wow! Brilliant -- this could be huge.

This would essentially allow you to create one-click installable apps that
could run on any service running AppScale.

~~~
eob
Let's not get ahead of ourselves :) Nothing is ever one-click.

~~~
catch23
Except at Amazon right? Theirs is patented!

------
lakeeffect
persistence was definitely a problem that we have over come with some tricks.

I would definitely hold off for the next version until persistent storage is
resolved.

~~~
easp
I did some digging into their docs. It looks like it is peristent as long as
the virtual disk for the virtual machine(s) are persistent.

