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