Tim - +1 to your message overall.
You raised a fascinating point: when the mass of developers rewrite their code to obtain maximum advantage of Appengine, Google will need to change pricing again. If you look at the early days, the main limitation with Appengine was the need to keep requests short. This induced developers to develop using task queues and other methods to emphasize small requests being run in parallel. In response, Google changed the pricing scheme to de- incentivize parallelism by placing a 15 minute surcharge on each instance that spawns to handle a parallel flood of requests. Now, it looks like datastore operations will be penalized. So people will rely more on memcache. Can we safely assume that when a large percentage of developers figure out how to throw 99% of our work onto memcache, we will see: #1. Increasing memcache error rates (or lower hit rates - same thing). #2. New pricing for memcache that 'properly reflects the cost of providing the service'? johnP On Jun 30, 1:48 am, Tim <[email protected]> wrote: > 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 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.
