Hacker News Reader

Comment by thurn | Hacker News Reader

The trouble with App Engine is that I'm now locked in to their API. They can raise prices and I have no real recourse unless I want to rewrite a lot of code.

View on HN

I was an early advocate of GAE but this is now my fear as well. When the new pricing was announced, the amount that they raised the service by seemed quite fair, but just the fact that it went up spooked me into being afraid of the fact that they could readjust the price at any time.

While I suspect they won't make it a habit of raising the price from here on out, the more I thought about it the more I've come to the conclusion that it makes sense to go with providers that use more standardized software stacks (despite how great not having to sysadmin is and the easy deployment from Eclipse to GAE), because that way I can take advantage of future competition of providers. If I go with GAE the costs to switchover become greater and greater the longer I'm there... so while they may never jack the price UP on me, they'll have little incentive to bring the price down due to increased competition.

Google has altered the pricing agreement. Pray they don't alter it any further...

we encourage you to look at appscale for app mobility. we're not interested in artificial lock-in from APIs. we're not that kind of a company. we're confident we can make the overall service superior. please note that we haven't changed the prices since we launched pricing, and GAE was in preview. that's an element to the notion of "preview". we're now taking it out of preview into a fully supported Google product. and part of that was to reprice so we have a sustainable business. after we announced the new pricing in May at I/O, we've actually seen our growth rate increase, since customers appreciate that we're committing to GAE.

Don't take this the wrong way, but when you are presenting yourself as a representative for a company (when you are using "we" to mean Google) you may want to use proper capitalization and grammar otherwise it makes your company seem like a popsicle stand instead of a Fortune 500 company.

AppScale deeply confuses me.

They seem to do a rare (once a year or so) push of whatever they've developed into a public source repo, and then just leave it there. No updates, no bug fixes, no community involvement, etc.

Their site looks like they're trying to sell me something, but there's no commercial product in evidence. And the whole thing seems to be done under the auspices of a university.

There's a link to their supposed development branch, bizarrely on launchpad instead of Google Code where they seem largely based, but it's empty.

I'm not really inclined to put time and effort into something whose model and motivation completely escapes and/or scares me.

We're very much graduate students and our testing cycle takes a lot of time away from doing research and publishing papers. We try to keep the main branch as stable as possible though for those who just want to get the latest and greatest. Our branches are pretty active and we do track issues/bugs and fix them, although you're right that we don't do so on our Google Code page. https://code.launchpad.net/~appscale-maintainers/appscale/ap...

OK, that answers a hell of a lot of questions, thanks!

I also now note that there's a "Contribute" link at the very bottom of your main site.

If I may make a couple other suggestions:

* Fixing the "Development Branch" link on your page (it's in the "Download" menu) which confusingly points to this totally inactive URL: https://code.launchpad.net/~cgb-cs/appscale/appscale

* Making some sort of statement on the Google Code page about your development practices and the fact that the bleeding edge is on Launchpad. People like me go to a Google Code page expecting to see the development site, complete with an active source tree, and get very confused when that's not what it really is.

Thanks for pointing that out. Updated.

You can have the best of both worlds, Java has standardized their web format to the point where you simply upload a zip archive (if you don't want to work with Java, almost all frameworks for jvm languages, including lift, are compatible with the framework).

I'm not up to speed on how compatible and recent it is, but AppScale bills itself as "Open Source Platform for Google App Engine Apps": http://code.google.com/p/appscale/

in addition to AppScale also look at the TyphoonAE project... these are open versions of the App Engine backend that claim to be fully-compatible to the SDK/client-side.

also to fight vendor lock-in, Python developers can create Django apps then run them on App Engine using django-nonrel or on any traditional hosted stack supporting Django; or move between then w/minor (settings.py) changes; don't forget data migration as well.

Not much familiar with GAE but how hard would it be to build an abstraction layer and have it deployed on, say, AWS or Rackspace, using HBase or Cassandra as backend?

http://code.google.com/p/appscale/

Maybe there's a business opportunity for a startup to offer hosting GAE apps on AWS?

The datastore API is probably the most involved for porting to. You would have to do both indexes and composite indexes for scalable queries, and implement your own transaction system. You can learn about how we do it for AppScale in our publications. Also check out the articles on the App Engine documentation, as well as the Google I/O videos for details on how they do it for Megastore/BigTable.

I have written multiple projects for GAE in Django and even ported one to it. The changes are seriously minimal. In the ported project, I had to change two lines of a lookup query that was a JOIN.

If you're concerned, use Django-nonrel, it's been amazing so far. Otherwise, appscale sounds like a good alternative.

If you're writing in Java, use standard API like JPA instead of native (that's what we're using with our site). I've tested some sample code on Amazon Beanstalk, and the code (with JPA) WORKED WITHOUT A SINGLE ALTERATION. It's not 100% obviously, e.g. if you use native types like Key, but the point is you CAN write your code to be compatible with any Java platform.

Reply on news.ycombinator.com