Hacker News new | past | comments | ask | show | jobs | submit login
AppScale: an open-source version of Google AppEngine (code.google.com)
70 points by chaostheory on Mar 24, 2009 | hide | past | web | favorite | 19 comments

From the home page: "AppScale is supported by Google and the National Science Foundation". Google? Wow.

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.

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.

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

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

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?

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.

"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?

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.

It's about lock-in, or removing lock-in in this case. Previously the cost of switching away from App Engine was pretty high; maybe now it's still not zero but it's a little lower.

And who says AppScale is just for private clouds? What if Yahoo starts offering AppScale hosting?

Their commercial pricing seems pretty competitive with other "cloud computing" offerings. What quota issues are you talking about?

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

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


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

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.

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.

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

Except at Amazon right? Theirs is patented!

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.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact