Why Google App Engine is broken and what Google must do to fix it.
(And no, Java support is most definitely not one of them.)
Rather than writing a lengthy diatribe, I am going to succinctly list the main showstoppers that Google needs to fix to make Google App Engine work:
1MB limit on data structures
Although this is hinted at in various bits of the documentation, it is not stated plainly anywhere so let me state it for the record:
Google App Engine does not support any data structure that is larger than 1MB in size.
This includes files. So you can't host that 1.2MB PDF you want to offer for download as part of your site.
The limit affects blobs, text, and any other fields in the datastore, as well as variables in Python (so you cannot get around the limitation by breaking things up into smaller pieces in the datastore and stitching them together later in code).
The only way to get around this limit is to stitch the data structure together on the client by making several Ajax calls. The number of use cases where this is useful, of course, is severely limited.
Among other things, the 1MB limit on data structures makes it nigh on impossible to run reports and makes having an administrative shell on the deployment environment pretty much useless as serialized results of queries with hundreds of items will quickly hit the limit.
1,000 item limit on query offsets
The datastore has always had a 1,000 item limit on query results. I don't have a problem with this.
However, they recently also introduced a 1,000 item limit on offsets. This means that you can at most get the 2,000th entity for a given kind.
Again this isn't documented anywhere.
Unless you have been keeping a sortable field (like a numeric index that you were manually saving) in your datastore, this new limitation effectively locks you out of your data beyond the 2,000th item for each kind.
The fact that such a radical change was introduced without any forewarning or even an announcement is, in and of itself, troubling.
Currently, the only way to get around this limitation is to make sure that you have a sortable field that you can limit your queries on. I would highly recommend saving a numeric key for every entity. This does mean, however, that you will be doing two datastore writes for every entity (once to save the record and get its numeric id, and another to write the numeric id into a separate field that you can sort on). This is both more cumbersome and will no doubt raise the risk of your running into another Google App Engine limit: The short-term high CPU quota.
(From what I've heard, the Google team is working on adding sortable keys in a future update.)
The short-term high CPU quota
Not only are your calls limited to returning in 10 seconds but if you actually try to do anything too stressful within those calls, you will quickly hit the short-term high CPU quota limit.
Thankfully, Google has raised this limit (and the other limits) for my app but plain vanilla apps are not as lucky. In my tests, I've found that the high CPU limit can be randomly triggered even in calls that return within a second. To tell you the truth, I don't actually know what causes these. I memcache nearly everything and try my hardest not to stress the system out and yet I routinely see the high CPU warnings in my logs for even the most mundane calls.
(I've also seen strange high CPU errors in my logs informing me that I am 1.0x above the high CPU limit which makes no sense at all.)
The short-term high CPU quotas must be removed. Not only that but Google must review how it handles quotas in general.
Quotas in general
When was the last time you saw an "over quota" error on one of your favorite web applications?
Google's handing of quotas is a major step backwards to the days of Geocities and "this user has used too much bandwidth" errors. Probably acceptable if you're hosting pictures of Little Timmy and Sally Jo's Summer Camp Adventure on Geocities, not so acceptable if you're hosting your next big web app on what you thought was Google's infinitely-scalable Cloud solution.
Simply put, they couldn't have come up with a worse PR campaign for Google App Engine if they had hired Steve Ballmer to handle the job.
Think about it:
You build an awesome new app on Google App Engine. You tell your friends. They tell 1,000 of their friends on Twitter who tell 1,000 of their friends and then, suddenly, you have all these developers hitting Google App Engine for the first time to see your app. Paradoxically, by doing that, they trigger the "intelligent throttling" "feature" in Google App Engine which freaks out and shuts down your app with an "Over Quota" error -- effectively making the "Over Quota" message the first impression most of your audience has of Google App Engine.
Not good.
Especially not good when your unique selling point is that your system can scale.
We don't care that it can scale. We care that it does scale. And that it scales when you need it the most.
But that's not the worst bit.
Admin? What's that?
Currently Google App Engine does only one half of what a web application needs (and does that only half well). As it stands today, Google App Engine is a highly scalable request/response system that is tuned to handle lots of tiny calls.
A typical web application, however, needs more than that.
While concentrating on making applications scalable, Google App Engine entirely ignores a crucial use case of any web application: administration. The administrative features of your web application may not be consumer-facing but they are just as important. They may include features for running reports or mailing all of your users. Key, essential tasks for any modern web application.
With Google App Engine today, if you have more than a couple of thousand members/records in your datastore, you can forget about running any sort of admin task.
A total lack of long running processes, coupled with the 1MB limit on data structures and the 1,000 limit on query offsets means that you cannot run reports or backups. (Not that there is a data backup system currently available for Google App Engine -- I have one that I wrote myself which used to work but is currently crippled due to the 1,000 item limit on offsets.)
Similarly, unless you knew to plan ahead and create a sortable key to query on, you will find yourself locked out reaching certain records in your datastore (for example, not being able to email all of your members).
These are core showstoppers for anyone considering building a real-world application on Google App Engine and I can only hope that they are at the top of the engineering team's list of new features.
25% ready for prime-time
As things stand, Google App Engine is about 25% ready for prime time. Once quotas are handled properly and the 1MB limit removed, it will be about 50% ready. The other 50% has nothing to do with scalability and everything to do with everything else that a typical web application needs. Specifically, long running processes and the ability to run reports, aggregate data, and perform operations on large data sets.
In effect, Google App Engine is entirely missing a separate mode of operation and this glaring omission must be addressed before Google App Engine can be deemed a serious web application platform.
Priorities and showstoppers
I really hope that Google is not working on adding support for other languages to Google App Engine, as they mentioned that they were at the Google Developer Day in London, when there are such fundamentally crippling issues with the platform that must be addressed first. Adding support for other languages to Google App Engine today is like sewing a new set of drapes for a house that doesn't have any walls yet.
In summary, before Google App Engine can be used for real web applications, the following issues have to be addressed:
- 1MB limit on data structures must be removed.
- Quotas must be handled optimistically, without crippling applications at the very moment that they should be benefitting from The Cloud. The "intelligent throttling" "feature" and short-term CPU quotas must be removed.
- The 1,000 item limit for offsets in queries must be removed.
- Support for long-running processes must be added.
It may just be that Google has to implement two modes of operation for each application on Google App Engine: one that is request/response-only and scales (i.e., basically what we have today, with better quota handling) and a separate admin mode that has long-running processes and isn't crippled by data structure size limits and short-term high CPU quotas.
As things stand today, running a real-world application on Google App Engine is a complete nightmare because the system completely ignores the essential administration-related use cases for web applications that we take for granted on other platforms.
Update: Several people have brought it to my attention that I forgot to mention another major showstopper for most applications, which is the lack of SSL. I ran into this early on, did my research, and found that PayPal was the only viable e-commerce solution at the time if your application needs to receive notification callbacks on purchases (ironically, Google Checkout requires SSL for its notifications API).
The Why Google App Engine is broken and what Google must do to fix it. article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Subscribe to my blog
Clarkson
William from Lagos
Kevin Schmidt
John Farrar
Louis Muloka
Mario
If you had the chance to go back in time, will you still use it, despite all the issues you have encountered along your way ? Or wait ’til is ready for prime-time instead ?
October 3rd, 2008 at 8:55 pmAral
In all honesty, no. It has lost me more time than I’ve gained. I would have gone with a pure Django solution.
Definitely play with it, but wait until they solve the issues I’ve chronicled here.
October 3rd, 2008 at 10:03 pmDavid Arno
Google app engine sounds a steaming pile of crap. I’m not surprised to hear you say you wouldn’t have used it if you’d known the pitfalls before you started.
The real killer issue though is the one you try to brush under the carpet as unimportant. The biggest killer for Google App Engine is that it is Python based. For it to be taken seriously in the enterprise space, it has to not only overcome the ridiculous limitations you list, it has to embrace either Java or .NET. Without support for one of those two (which are the only two serious enterprise-scale solution bases out there), it will remain a small scale solution for small scale needs.
October 3rd, 2008 at 10:24 pmDwight Merriman
Your concerns are all valid: clearly for any non-trivial application one will need long running processes, not to mention the ability to do a table scan.
We have always had this intent with 10gen, that long running processes are part of the system. By default, page requests on 10gen error out after 8 seconds. However, one can explicitly declare that an operation is long-lived. Further, our management system will soon include a “cron” facility for background tasks that run on a regularly scheduled basis.
I would encourage anyone interested to check out the alpha version of the system: we would really want feedback similar to what you have written in this post. It is very early in the “Platform-as-a-service” space. These systems will be incredibly liberating at maturity, but it is still early days. btw: I am not trying to be critical of App Engine at all; our system has plenty of rough edges itself, and thus is labeled as alpha currently.
October 3rd, 2008 at 10:29 pmMrChucho
I would also say that the restriction that the “first ordering property must be the same as inequality filter property” is an impediment to adoption. For example, the following simple query is not allowed:
Post.all().filter(”created >= “,last_24_hours).order(”-comments”)
October 3rd, 2008 at 10:32 pmNiall Kennedy
The 1 MB limit is likely due to App Engine’s inability to handle partial downloads via Range and other methods. Without Range support (file fragments) App Engine limits file sizes to what can be consumed by agents in a single gulp.
October 3rd, 2008 at 10:32 pmAral
@David Arno:
No, Google App Engine is not “a steaming pile of crap”. It’s a brave foray into making The Cloud accessible to mainstream developers. And, like any other emerging technology, like any other venture into uncharted territory, like anything else that is worth doing, it has issues.
Who the hell cares if it is taken seriously in the “enterprise space”? Personally, I find the “enterprise space” supremely, mind-numbingly, and unequivocally b-o-r-i-n-g.
I know it’s probably ridiculously difficult to believe but, *shudder*, Google App Engine isn’t _aimed_ at the “enterprise space”. And thank goodness for that.
October 3rd, 2008 at 10:51 pmNick Winter
Do you need a sortable key to query on, to get a lot of records? Why won’t any old sortable property do, if you’re just looking to retrieve all records? The only Properties that aren’t sortable are Text and Blob.
My models are probably structured much differently than yours, but using key names for everything (as opposed to auto-assigned numeric IDs) has been great. Not useful for sorting, but useful for many other cases. Giving up key names for IDs just to have fast lookups that match a sortable Property seems harsh.
I’ve run into a lot of cryptic high CPU warnings, as well. A lot of them seem to be traceable to having to do a lot of imports, often when a new main() is started. Have you checked that, or do you have a workaround for that problem (I’d love to hear if you do)?
By the way, I used your GAE SWF project to get started with App Engine and with Flash, and it was immensely wonderful. Thank you!
October 3rd, 2008 at 10:57 pmDavid Arno
@Aral,
From Google’s own blurb on their app engine:
“Google App Engine makes it easy to build scalable applications that grow from one user to millions of users without infrastructure headaches.”
I think you’ll find “millions of users” is 100% within the enterprise space that you seem so dismissive of. Sure their beta release is aimed at small scale stuff, but their aim will be to scale it up big time in the future by charging for the privilege of exceeding the quotas that are causing you such headaches. If they are serious about the “millions of users” scalability, then Java support will become a de facto requirement.
October 3rd, 2008 at 11:14 pmWilcox
“Adding support for other languages to Google App Engine today is like sewing a new set of drapes for a house that doesn’t have any walls yet.”
LOL
October 3rd, 2008 at 11:57 pmMichael
You’ve hit it right on the head. Your article should be required reading for anyone considering building an on Google’s platform.
October 4th, 2008 at 12:00 amAral
@David Arno:
Read this to learn what enterprise software means: http://en.wikipedia.org/wiki/Enterprise_software
October 4th, 2008 at 12:20 amLee McColl Sylvester
Millions of users require a good server, not enterprise features. As for Java support, even ASP 3.0 can handle a HUGE user hit. Besides, it’s far easier to get Python to handle more users as standard than a Java application that has been built by someone unused to developing for such large numbers. In my opinion, Java support would be a waste of time, unless it was a bespoke VM which Google have been known to tinker with
My take on Google App Engine is simply that I’m not a fan of Python. Sure, it’s a powerful language, but I don’t like its syntax… It’s too reminiscent of BASIC languages of old, and for some reason that’s a big deal for me
I think I’ll wait for them to fix the bugs AND add another supported language. PHP would be nice!
October 4th, 2008 at 12:30 amDavid Arno
@Lee
I agree that Python’s syntax is nasty (and that it is a big deal, even though it ought not to be), but PHP? It’s OK I guess, but it’s C# that kicks arse as the best language around in my not-even-slightly-humble opinion. Sadly for me, I picked the other half of the enterprise space for a job (it’s sweet that Aral is trying to teach me what enterprise is therefore
) and so I’m “stuck” doing Java & Flex.
Anyone using JEE ought to be able to handle big numbers of users in their code. If they can’t then they shouldn’t be doing JEE. Of course, there are plenty of people in the world that shouldn’t be doing doing what they are doing though…
October 4th, 2008 at 12:45 amSimon Willison
Lee: give Python another shot. Most PHP programmers I know who have looked in to Python have found it a much more pleasant programming environment, once they get over the first couple of hours of being shocked at the required indentation.
David: is YouTube enterprisey enough for you? Written in Python.
October 4th, 2008 at 12:54 amLee McColl Sylvester
@David : yes, C# is a great language, but the .NET CLR sucks big time. I hate using bloated runtimes, even if I’m not managing it directly. Of course, Mono is a great alternative, and you get to use C# with that, too.
@Simon : I wouldn’t want to be tied down as a PHP dev, but it certainly is more flexible. Personally, I’d love GAE to use the Neko runtime, but I don’t see that happening for a while. It’s quite funny, really, but the biggest turn off with regard to Python is its messy CFFI. If that was right, at least, I’d probably use it more
October 4th, 2008 at 1:35 amAdam Fisk
Great writeup, Simon. I agree it’s pretty shocking how hidden many of the App Engine limitations are — you typically don’t know about them until they smack you across the face.
To me, App Engine only makes sense as part of a hybrid solution, i.e. working in tandem with other traditional servers to fill in the gaps you mention, although the pure database limitations don’t have that luxury.
@David Arno: languages are rarely the limitation in making any system hold up under any kind of strain
October 4th, 2008 at 2:31 amAdam Fisk
Er, I mean “great writeup Aral.”
October 4th, 2008 at 2:32 amNaum
Python and the watered-down Django that runs on AppEngine is not a major hurdle for me. While I prefer Ruby or even PHP for web applications, Python is more than suited to web application tasks.
However, the items listed in the article are absolute show stoppers…
* …1M limit on files, date entities, etc.… …early on, created a simple app that relied on /dict/words but had to restrict to under 9 characters as the file upload is capped at 1M.
* …I was bumping up against CPU quotas for simply accessing one datastore record and unpickling a 200-300K compressed object (and for some transactions, storing it back).
* …OK with non-relational DataStore storage, and even the 1000 call limit as I think it obscene to do that much DB reading in a single transaction. However, the lack of aggregate functions and inability to run batch jobs really put a weighted damper on constructing maintenance functions. I’m all for “you’re in and out in a snap” for the user transactions, but there are functions and reports where you need hit the complete data repository (in batch/offline mode). Or even access summary data without expensive I/O/CPU expended.
* …these limitations make it impossible without extraordinary AJAX hacks to backup your application data. Unless you keep it under 1000 records…
October 4th, 2008 at 3:29 amLiveCrunch
They should also fix the search feature.
Btw I just tweeted that
October 4th, 2008 at 5:59 amRichard
But (IMHO) it’s meant to be limited while they’re in this early-adopter phase so people don’t impact each others’ apps too much. They’ll use this phase to build out what people *really* need, based on the tons of feedback they’re getting. I’m amazed they produced something that is good enough to have these issues as the first things we want to talk about!
What I’d like is better communication and a roadmap. When will they drop the limits?
October 4th, 2008 at 7:44 amNDG
“I would highly recommend saving a numeric key for every entity. This does mean, however, that you will be doing two datastore writes for every entity (once to save the record and get its numeric id, and another to write the numeric id into a separate field that you can sort on).”
Any reason not to use a DateTimeProperty with auto_now or auto_now_add?
October 4th, 2008 at 8:38 amFernando Correia
Thank you Aral for this great writeup. Your blog was a great help and inspiration while I was learning App Engine. The reliability issue is a huge one for me, and the lack of batch processing can prevent you from doing proper administration. I would settle for other Web hosting alternatives that are not so restrictive.
October 4th, 2008 at 2:14 pmShane Conder
@David re enterprise: I think all Aral is trying to say is that, regardless of scale, GAE is meant for apps targeted at the public, where things like security, privacy, and accountability are the most important items, no serving up millions of pages a day. Unfortunately, GAE doesn’t do that, either.
@all
First, are these limitations supposed to be indicative of the final (or beta, as Google will call it) version of GAE that will be available after it’s out of its beta (aka preview release)? Or are they just limitations imposed on the preview release to keep it from being used by release software?
Second, I see evidence of some of these limitations within Google’s own apps. Do we think these limitations are about the approach to the problem rather than the problem itself? I think it’s safe to say, the most of us are comfortable thinking in relational databases with PHP. The Google datastore is not relational and they have figured out how to use python for their apps (or so we’ve been led to believe). This thought process and approach is found in many platform shifts. The problem is, there isn’t much said about how to approach problems in this new way, if that is really the intention. In addition, things like tiny query offset limits seem to go against that and strengthen the argument that they may just be preview release limits. On the other hand, with a platform optimized for search and showing folks on a few things before they search again, can work with this.
I agree that, as is, GAE can’t handle the sorts of things external folks need to run apps within Google, such as create administrative interfaces, backups, etc. Those things, though, aren’t an issue with Google, since it’s all running on their servers and they can approach that issue from behind.
October 4th, 2008 at 2:26 pmpoko
the missing https protocol is also really annoying
October 5th, 2008 at 2:21 amray
What is really strange - Google is reluctant to document any of these issues. I posted a simple request to add the 10 second (I thought it was 5 seconds)limit to their online documentation and they responded by saying that the current wording was sufficient. I pressed further and I was given a link to add my request as a feature request. Maybe if we all pressed further they will at least update their documentation. I lost weeks of work porting from localhost to production (localhost doesn’t have the 10 second limit !!) when I discovered the issue.
On the positive side, my developed application is FANTASTIC! It screams fast. I equate it to climbing a mountain. You can’t look down at relational databases, FTP, Java, PHP etc. You just continue climbing. When you get to the top the view is incredible! Be creative. Think AJAX. Use Mashups. Add everything to cache. etc. Here is one view from the top - http://www.ecmhub.com. Tell me what you think?!
October 5th, 2008 at 5:02 amlowell
@david a. => f__k enterprisey-ness. voluntarily censored because i’m a guest in aral’s house.
oh, and david..
“it has to embrace either Java or .NET. Without support for one of those two (which are the only two serious enterprise-scale solution bases out there), it will remain a small scale solution for small scale needs.”
.. youtube’s written mostly in python. hardly small-time, wouldn’t you agree?
..
October 5th, 2008 at 5:54 amaral.. thanks for the article.. as a rubyist, gae is one of those things i had a bunch of questions about but i didnt feel like learning python just to see what its all about. valuable insight, def appreciated.
Dinesh Varadharajan
Good writeup Aral. GQL is also very restrictive. no OR and no joins and not more than one inequality in queries. Without any of these it’s almost impossible to do even a basic data analysis with stored data. Forget about big enterprise applications. Even small business apps would need data analysis/reports.
October 5th, 2008 at 7:46 amLee McColl Sylvester
@Lowell : Eve Online’s server is written in Python, too, and that holds the record for most simultaneous gamers on one server… And I believe it didn’t struggle even then
October 5th, 2008 at 10:39 ampoko
the lack of https is the second most popular issue in the gae issue tracker:
http://code.google.com/p/googleappengine/issues/detail?id=15&q=https&colspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log
so i believe it’s a showstopper too
October 5th, 2008 at 1:30 pmAral
Thanks, poko, I updated the article to mention the lack of SSL.
October 5th, 2008 at 5:12 pmGérard Mulot
I developed an application with LeeBeLLuL that communicates with Google App Engine in SOAP. I mainly use the DataStore, process are done in the PC.
October 5th, 2008 at 5:50 pmI think GAE is an effective platform with very good response time, whose implementation is easy.
http://www.leebellul.com/Site/APPLICATIONS/Ressources_Humaines_V1.html
Prabhakar Chaganti
Nice write-up Aral. Google needs to work on beefing up the existing offering before adding additional language support.
October 5th, 2008 at 6:53 pmJeffrey Rosen
Here’s another one:
When you first mess around with Google App Engine on appspot, you are totally blown away by the speed. The ping time to an appspot address is extremely low, in California, it’s around 6 ms. However, eventually you need to migrate over to your own domain. You would think this would be just as fast, but unfortunately, ghs.google.com is way slower and your ping time goes from nearly instant to actually slower than the average hosting provider.
Compare: http://jeffr.appspot.com and http://wolfire.com
You make a ton of good points, but I think the biggest issue is that Google is totally opaque with App Engine. I honestly have no idea what to expect in the next release. What is really frustrating is that Google has tons of engineers working on this thing. They’ve even hired the creator of Python for this project, from what I hear. However, month after month, they release these puny little updates that fix tiny little things like path parsing issues in the Windows SDK.
I want to see real updates that get to the core issues that people have been complaining about since launch.
October 5th, 2008 at 8:31 pmenterprise THIS
@david arno and other idiots
enterprise scale is but a small slice of web-scale, idiot. name an enterprise that handles even a tenth of the load of youtube
October 6th, 2008 at 2:23 amLee McColl Sylvester
There’s no reason why an enterprise app couldn’t serve the world simultaneously. It’s all about scaleability, not complexity. Though, of course, complexity decreases ease of scaleability.
October 6th, 2008 at 9:29 amAlex Kerr
I don’t like the underlying mentality of this article which is the expectation that Google App Engine should be good, that we should use it, or that we should show some sort of deference or respect for it. It’s like the bad old days of Microsoft allegiance, because it’s a big successful American co. and we can’t possibly be seen to criticize one of those now can we?
Treat App Engine like it was from any two bit company you never heard of. It sounds like a mess, a failure and a joke. Google or not. Maybe it will get better and be the best thing since sliced bread. Maybe it won’t. For now I wouldn’t touch it with a barge pole, and will stick with the far, far better Amazon services.
And for the record I like Google’s other software and services, where they’re good, and have earned it. It will take more than a company’s size and success (and American origins) to impress me.
October 7th, 2008 at 12:52 pmLee McColl Sylvester
I really don’t think you can compare it to something a small time company has built. Google has a stack of cash, it has a team of top developers working on it and Guido Van Rossum himself is modifying Python to interact with it. Okay, so innovation doesn’t come from money, but it can sure hire those that are good at doing so.
The only real issue is that GAE is a relatively unique concept. I say relatively, because its constituent parts are certainly not. However, it is a good idea, and when Google are finished, it’ll be an attractive platform.
October 7th, 2008 at 1:55 pmJason
ast read AND write access would be great IMHO
October 7th, 2008 at 4:52 pmJohn Wright
I want to chime in on “enterprise” versus Facebook, YouTube. Enterprise means small, usually a few thousands users. Facebook, YouTube, Google play on a totally different level and have developed custom scaling techniques that are just now being published to the outside world such as memcached, sharding. I am a contractor for “very large enterprise company you know X” working on an internal platform app. Our app will serve 3000 users. There is nothing about enterprise which should be equated with scaling. Also many (not all) enterprise IT organizations are very brittle and barely functioning. Many enterprises can only digest a very small set of technologies that they have a ton of trouble managing and mastering. They are scared of new technologies because they barely keep their Java app servers running. It once took a company I worked for 2 weeks to setup a JBoss datasource. Enterprise software to me represents not only something boring, but also something very technically primitive. That is why we are trying transform my company X into less of an enterprise and more of a software as a service company.
October 11th, 2008 at 6:39 pmBruno Paul
GAE now support SSL : http://googleappengine.blogspot.com/2008/10/announcing-https-support-for-appspotcom.html
October 28th, 2008 at 10:52 amAndyI
good write up - great discussion folks! Wow.. I’m only a month late to the discussion.
Anyhow, to chime in on languages - I’ve learned over the years that they’re just tools in the toolbox - some better than others for certain problems - and therefore best to look at the problem first and decide if the language is suitable for needs over a given time frame. Python seems to be a decent choice - easy to learn and easy to connect to native code on the backend (when needed.)
Currently I’m quite fond of PHP and Apache’s mod_rewrite as I’m implementing a RESTful architecture with a massive URL space that boils down into a much more limited code/logic space on the backend.
Google App engine and other “scalable” systems such as amazon’s services are interesting because of the claimed scalability, the risk being that if the system doesn’t deliver, or key constraints change arbitrarily or without appropriate notice..poof, there goes your product.
yo ho ho!
November 12th, 2008 at 6:38 pmpete
Nice post Aral, I myself am suffering the pains of a “Beta” Appengine. Although I think given time, most of these issues will be addressed.
Arno… You should take time out from shooting your mouth off about things you have no idea about and do some research. Java/.NET are like VHS, it’s not the best, but got the right backing at the right time. From an organisational perspective, Java is responsible for some of the slowest, most ineffective, bohemeth systems on earth. Why? Purely because there are mindless eeejits who have no idea what they are talking about and jump on the bandwagon.
November 15th, 2008 at 10:09 amThe first mistake of any project is to ignore the requirements and just jump into a technology because somebody else has branded it *enterprise*.
Prathapan Sethu
We are building our intranet HR app on Google App Engine. While I like its speed, on the flip side there are too many limits as pointed out in this article, and Google needs to remove them asap. Also, BigTable is not relational and I see that MySQL developers have a problem switching to the non-relational way of doing things. Google needs to support developers with plenty of documentation and example code, so they can understand the concepts learn this platform faster. They also need to communicate their roadmap.
I think GAE is a wonderful platform, but unless Google moves fast and fixes the problems, they are going to lose developers.
December 8th, 2008 at 2:48 pmAndy B
As far as enterprise uses go, I think David is correct that Python is viewed with suspicion by businesses. This is in part due to the language itself: businesses prefer to be somewhat more conservative. (e.g. static typing, C-like syntax, etc.) Dynamic languages seem scarier and less reliable.
This is not, however, a fatal flaw of GAE. Mostly I think Java and .NET are popular in the enterprise space because of the supporting corporations. Each is quite good on its own, but where would Java really be without Sun, or .NET without Microsoft? The association between Google and Python will give it plenty of credibility as a language. There is still the problem of programmers not knowing it, but I agree that Google should work on the core functionality before adding support for other languages.
It sounds like these problems, although severe enough to be show-stoppers now, might not be as intractable as the scalability problems that GAE is meant to solve. Hopefully Google will fix them soon for its own sake.
December 9th, 2008 at 3:33 amKris
1. It’s currently free.. Who in their right mind would use a free hosting service to deploy a serious project? Nobody!
2. It’s a beta service /preview release.. and will become something more like the AWS platform over time (limits and restrictions won’t be in place but it will cost you)
If they made it available for free with no restrictions then everybody would use it a host huge static files globally for free..
December 10th, 2008 at 2:18 amnate
Enterprise IT has to be “Reliable” above all, it won’t be long before clouds like GAE will be more reliable than the servers in the local data center.
Does someone really have to write a pretty printer that adds in curly braces into Python code for it to be read by all the “C” family programmers?
And, I agree no-price, no-knowing.
December 17th, 2008 at 7:30 pmJeremy kajikawa
SSL for serving ?
or SSL for accessing external sites?
Ive had no issues with SSL serving and Im only using the AppEngine
as a customized coded front-end for the googleplex database
SSL access to offsite resources will be part of what I’ll find out about
when I finish seperation of the admin site from the service site.
personally I am trying to setup the admin site as an own site seperate
from the site administrated.
so far together or apart seems equally as disconnected for all the parts.
December 18th, 2008 at 12:45 amAral
@Jeremy:
SSL as in accessing your site via https://www.mylovelyapp.com. You can’t do that. With the newly-introduced SSL support, you can access your app at https://mylovelyapp.appspot.com but you cannot carry across a session between the two. So, if you’re using a custom domain for your app, Google App Engine still doesn’t support SSL. It only supports SSL if you’re serving your app from appspot.com.
December 18th, 2008 at 12:46 pmAral
@nate: As far as I’m concerned, C can keep its curly brackets. With the amount I type, I’d rather type less
December 18th, 2008 at 12:47 pmstelg
Aral,
Compliments with your article.
Meanwhile using https is a piece of cake. Just adapt the yaml file.
The storage limit of 1 MB is ridiculous!. Youtube (=Google) and plenty other systems allow much more!
The CPU limits are painful. It is easy to get over the short-term high CPU quotas.
Sending more than 10 emails at one submit request is impossible. You have to wait every time 1 minute before a next group of 10 emails can be submitted.
Using Blind Carbon Copies (BCC) does not work at all.
So a lot to improve for Google. The term SCALABLE is not yet fulfilled by Google!
To end with good news: The reponse times on normal (smaller requests) are great!!
December 28th, 2008 at 8:02 pm