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.
