I cannot agree more. I have expressed the similar opinion three times since the discussion began, and I saw some others feel the same way. But so far, I'm convinced the change is inevitable, and I'll bite the bullet and stay, until I have a choice.
Will On Thu, Jun 30, 2011 at 11:46 PM, johnP <[email protected]> wrote: > One more related point. > > It makes sense that it's important for Appengine to generate profits > for Google. > > I'd like to propose one thought: It might be cheaper for Google to > lose money on Appengine than it is to lose trust with the developer > community. > > Right now, a singular event is occurring. Google is at great risk of > very publicly and deeply breaking trust with the developer community. > Developers started using Appengine because they trusted that the > essential value proposition would remain stable. The depth of > commitment from the developers was great: developers coded to a locked- > in platform. Although Google had a preview stamp on the front page, > it tacitly encouraged the developers (by producing lectures about map/ > reduce, for example). I'm writing to establish that the potential > 'breach of trust' is not imagined, but founded. > > By making the drastic change, Google will achieve the following: 1. > Developers might move away from Appengine because it will no longer be > so appealing. The objective of turning a profit might not be obtained > if developers leave. 2. For years/decades, whenever Google launches > a new endeavor, the simple counter-argument "Remember Appengine > (Appengone?)?" will be the nuclear one. > > By doing right and rewarding developers' trust, Google might achieve > the following: 1. Developers will continue using the platform. They > already have shown that in its current state, it's appealing. 2. > Google engineers can do what they are best at: solve the technical > issues related with making the platform run efficiently. 3. Develop > a real breakthrough in computing. > > I propose that the real decision-making at Google should not be, "Is > Appengine profitable or not." It should be, "How much would it cost > to subsidize Appengine + continue to develop it until it works as > originally promised" vs. "How would a generalized breach of trust > affect Google's future." > > I don't think I'm being excessively alarmist, because many developers > on this board have written, "The new pricing model makes the platform > non-viable for me." Appengine was highly promoted, so if this change > (dare I call it 'strategic error') imprints into the public mind as a > breach of trust, the impact will be very public, very deep, and very > lasting. > > johnP > > > > > On Jun 30, 7:51 am, johnP <[email protected]> wrote: > > 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. > > -- 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.
