On Thursday, June 30, 2011 7:06:03 AM UTC+1, Ikai L (Google) wrote:
>
> The plan that is in place will be very close to what we launch with,
> because when we looked at different pricing plans, our analysis of previous
> usage trends and billing led us to believe that the one we have announced
> was the most balanced in terms of being developer friendly as well as
> sustainable. Unfortunately, we did understand that the changes would not
> work for some people. The most constructive discussion we can have right now
> is around how we can make this pricing work. What tools can we provide? What
> data do we not display? How should support work? And so forth. Throttler
> knobs, for instance, are an example of a feature where much of the
> requirements were sourced from constructive user feedback. Raising the
> priority of Python concurrency was another one.
>
>
OK, so keeping on topic without wanting to sound like I'm whinging:
Executive summary:
What I want up front is a clear statement about what GAE is aimed at today,
something definite that lets me plan, not just marketing speak, but "this is
what it is, we're aiming at this kind of use, not this, that or the other".
This would let me decide whether I should keep with what I'm doing, or adapt
to the new pricing plan as it stands, or plan to move away from GAE if I'm
not the intended market. I can try and infer this "positioning" from the
pricing plan, feature announcements, release schedules etc, but that's
working by side-effect... can we have some clarity and statements of intent
please ?
Now if that seems a bit of a brutal request from nowhere, there's a longer
version below that fleshes out some details about what this means in my
case, and the way I'm struggling to see if my use is aligned with the
intended use of GAE - I don't expect the whole list to read it (hence it's
below the sig), but I hope it illustrates my request
Regards
--
Tim
Background and specifics:
I'm building a single-page-webapp, so my profile of usage is for the user to
fetch a page that pulls in a bunch of JS once at startup (+images/css etc)
and then does a load of smallish JSON based AJAX operations, typically read
a bunch of stuff, then write back updates (think reading a document
consisting of a collection of smaller pieces and writing back partial
updates, additions and deletions as the user works on it).
I originally thought AppEngine was ideal for this sort of "rich cloud app to
replace desktop app" (hence the name) and was aimed at this sort of use
rather than, say, hosting blog engines or more traditional static sites, and
the introduction of the Channel API reinforced this impression.
But the new pricing and the cost limitation it puts on the _number_ of
datastore operations (regardless of size) is my biggest immediate concern in
the pricing plan. I can cache user operations in the browser for a few
seconds, but I'm still likely to have lots of little updates to small
objects, and it seems AppEngine isn't being priced to this model of use, and
so while there are things I can do that would improve my position as to
costs, it makes me wonder if my type of app is not the target market.
For example, I could move away from storing the "doc" as a collection of
small objects but instead store it as a single big blob, memcache it on
read, then apply the partial updates to the memcache image and write back
the entire blob on each update. This would reduce my read costs (one read as
opposed to lots) and my write costs (simultaneous updates to multiple
fragments would be saved as one). But this feels like optimising to the
pricing model (and would involve quite a lot more RAM usage for example),
and treats the DataStore as little more than a dumb data file.
So my choice is to re-write for the current pricing plan and hope it doesn't
change (as everybody else adapts what they do and the team react to adjust
pricing accordingly), or plan to move to something else. Either way, it
seems prudent to then NOT take advantage of other high value features of GAE
which would tie me to the platform, to reduce GAE in my plans to little more
than a commodity hosting system rather than the higher value offering it
should represent.
Predictions, especially of the future, are always hard, but what would help
would be a fresh positioning statement from the App Engine team about what
the platform aims to "be", who it is aimed at (and maybe who it's NOT aimed
at), what it aspires to etc.
I believe fundamentally we're currently all struggling to understand if GAE
is a strategic move for Google or a leaking of an internal system for
outside use, if it's aimed at the dynamic world of small apps ("app store",
python) or at large enterprise level operations ("Engine for running your
organisation as an application", java), if it's aimed at people who need
client-host bandwidth or complex back-end processing facilities, and we can
only determine this by side effect of announcements to pricing models and
features.
If I'm the anti-market for GAE, I won't be offended, I'll just plan to move
elsewhere; if I am the target market, I'd be happy to change the way I work
to fit in nicely, but I'd appreciate some indication to avoid me having to
do both.
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/LWd5ZkI5zIIJ.
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.
