5 ms·
Is Google App Engine successful?
- bprater 18y agoThe lack of any real evangelism is hurting App Engine. If Google was doing a better job highlighting companies or projects using the service, posting interesting articles, actually improving the service based on feedback -- they might have gained more traction by now. They are wholly inconsistent, the last blog post was a month ago. You can't just launch a service and wait for ... magic. You'd think that Goog would understand this. App Engine isn't dead by far, but it could be a much bigger player in the cloud space if someone at Google would wake up.
- csytan 18y agoInstead of following the blog, you might want to check out the appengine group: http://groups.google.com/group/google-appengine http://groups.google.com/group/google-appengine I'm actually quite impressed with their work. The platform (despite its limitations) is extremely easy to work on and they seem to be implementing features & fixing bugs at a good pace. They also hold a bi-monthly IRC chat with developers.
- amichail 18y agoI've built http://readmytweets.com http://readmytweets.com using the GAE. Even though it has problems (e.g., no distributed transactions), I still predict that GAE will be very successful. But that's a problem in a way: your competition is about to increase several orders of magnitude as server cost goes to zero. Think of all those high school and university students who will be attempting their own web startups.
- koenbok 18y agoWell, the platform also seriously lacks some stuff to start developing anything serious on it like: being able to buy more quota, fulltext search, a weird 1000 result limit and most importantly bulk data editing/backup/restore. But we host our http://www.versionsapp.com http://www.versionsapp.com site on it and that works extremely well: http://www.madebysofa.com/#blog/appengine_hosting http://www.madebysofa.com/#blog/appengine_hosting
- anewaccountname 18y agoGorgeous site.
- bdr 18y agoGoogle has failed to execute well on GAE. What's the point of automatic scalability if you have usage caps? Why has it taken so long to get a payment plan? The platform isn't the right choice for anyone yet, and it's taking too long to get there.
- joshsharp 18y agoAgreed. It's not a lack of evangelism, it's arbitrary usage caps and result limits that make GAE a pain to use effectively. Although I suppose you could say this means it also suffers from anti-evangelism, because after using it for a project I warned everyone else that was interested, "It's not ready, don't bother."
- flashgordon 18y agowell its too early a call, but one thing is it is not unsuccessful... you are all aware with the limitations (eg comet support and cron jobs being the biggest), but it is still not bad for quick prototyping and even releasing sites with medium levels of complexity (ive written a simple chess site - wizchess.appspot.com - does the basic game play and all but lots lots lots of polish required)... but it certainly goes with google's philosopy of "fail often, fail early" (or the other way around).. essentially they are developing the api in tangent with developers who require new features though it has been slow late i think...
- ChaitanyaSai 18y agoI built an app on it a while back http://gflix.appspot.com http://gflix.appspot.com to go with the Netflixprize competition. While the inability to bulk-upload data (without workarounds), and the data size limits are rather annoying, it does work well and looks promising, especially given that it is only a few months old. I think the primary advantage is being able to harness Google's architecture for zippy data retrieval, but they then handicap it by putting limits on how much data you can dump. They probably will offer a tiered pricing structure to allow massive dataset uploads.
- deleted 18y ago[deleted]
- andr 18y agoI think it is, but not for the reason you think. Google is slowly porting a lot of their own applications to GAE and those savings alone make it worth it even if it never gains major market share with the outside world.