Thank you for your reply Siva...a good deal more than 2c's worth! I have also checked out AWS and I agree that right now it is "infinitely more flexible".
But Google has definitely put the cat among the pigeons with the GAE paradigm and I think that this is ultimately the level of abstraction at which developers will want to work at. I feel the current data store limitations are a legacy of Google's business focus and there is no reason why they (or a competitor) cannot offer an alternative tighter datastore optimised for financial applications and such like, perhaps at the expense of geographical redundancy which I think is over-rated for the vast majority of web applications. If not, I can see Amazon or Microsoft filling that gap very quickly. It concerns me the way Google has launched this service. It could very easily backfire and drive a lot of developers away although that is probably underestimating the loyalty of Google's user base - but that can only get you so far! Google has set a very high bar and will need a massive development effort to get this service out of the labs and into the real world. At a very mundane level, the absence of a fixed currency/decimal data type sort of sums up my concerns about Google's priorities with the GAE. Of course Python has also been slow in addressing this anomaly! When will respected computer scientists realise that floats simply don't hack it in financial applications? I have a lot of respect for Google and I do hope that GAE makes it to prime time - but the GAE strategists need to look beyond their limited world view and hammer out a concrete roadmap which will demonstrate how this wonderful initiative can be applied to wider applications, e.g. accounting, payroll, etc. Rgds, rvjcallanan On Dec 5, 7:15 pm, Siva Velusamy <[EMAIL PROTECTED]> wrote: > Here are some of my thoughts. I have built only 1 application (http:// > envy.appspot.com), and we didn't spend too much time on but, but I see > a few issues with GAE. > > GAE makes you focus on scalability right from the start. This is > annoying because of the following reasons: > - over 90% of the websites don't require it. > - When I build something around an idea, my initial requirement is to > get it out to people first, and then worry about scalability...if > there is any traction. I don't see why I have to first optimize it > without knowing whether it is worthwhile. > - GAE also makes it tough to figure out if your app will get any > traction. This is because as soon as you launch an app, it will > possibly go over quota (esp. high cpu) and you cannot advertise your > website until after you've fixed it. > > The next issue, is that your preferred language/runtime/library/etc > will never be available on GAE. GAE relies on modified version of > certain runtimes, and no matter how many people work on it, it won't > support everything. Take for instance, Py3k. It will probably be a > while before it is supported. > > The third issue is the lack of flexibility. You are forced to follow > the GAE methodology - whether it be optimizing your site, or running > background tasks (when it is supported), or anything else. You could > think of 10 different ways to do it, but GAE will probably only > support only 1 of those, and you'll have to learn quite a bit to > figure that out. Which is fine technically, but not that great when > time to market is your primary concern. > > I think that GAE is perfectly fine if you know exactly what you want, > and you know that all your requirements are already satisfied by GAE. > If your requirements could possibly vary, then it is tough to predict > whether it will be supported, or how much effort will be required on > your part. In that regard, I find the Amazon EC2 approach to be > infinitely more flexible. > > My 2c. (And keep in mind I'm still learning, so these impressions may > not be accurate). > > -Siva > > On Dec 5, 10:42 am, rvjcallanan <[EMAIL PROTECTED]> wrote: > > > I am about to take the GAE plunge (at least in the experimentation > > sense). > > I understand the current irritations and I am hopeful that these will > > be overcome in due course > > > But I am very curious how far Google can take this thing... > > > A key question on everyone's mind: > > > Can we assume that GAE developers will eventually be able to produce > > GAE apps with similar complexity, reliability, scalability and > > performance ballparks as Gmail, subject of course to hosting fees? > > > If the answer to that question is "YES", then I am am convinced that > > GAE will eventually be able to host sophisticated financial > > applications that are not currently in the GAE sweetspot, e.g. > > accounts, payroll, etc > > > Or would it be more realistic to assume that GAE developers will never > > really be able to leverage what Gmail's developers can leverage? > > > Looking beyond the Gmail comparison, I see lots of problems with the > > GAE datastore for financial applications e.g. the absence of joins, > > aggregation, etc. I understand that these limitations are inherent to > > the BigTable paradigm, yet I already see posts by developers showing > > how these limitations can be overcome. Solutions tend to revolve > > around de-normalisation and other forms of data redundancy together > > with a sizable smattering of code trickery. All very, very botchy and > > alien to the GAE philosophy of removing much of the the tedium of web > > development. > > > I am wondering if it will ever be possible to write an abstraction > > layer that will present the underlying GAE datastore as an SQL > > database albeit at a cost in terms of data efficiency, CPU cycles and > > bandwidth...or is this completely missing the point? > > > Bear in mind that I am thinking a few years down the road. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
