I agree with the fact that startup web application dont need to scale
immediately. For example in a community or social networking
application. The only time you'll need to scale is when people started
using your app. If not, you'll end up thinking of a new idea, creating
and releasing a prototype. GAE makes development of web application a
bit harder because the development is not like the "usual" way we
create web apps.


On Dec 6, 3:15 am, 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to