While I agree that some people do compare apples to oranges here, I cannot accept your claim that such changes in pricing were to be expected. There's no precedent for a change in pricing model like that, and consider this: Gmail was in beta for a very long time and no doubt is a losing article for Google, but would anyone even consider to start charging a penny for every email once it was leaving beta? (But hey, 5 free emails per day!) How would seemingly valid arguments about developer salaries and sustainability and data portability hold then?
I understand that the change needed to happen, but it was handled by putting developers completely out of control and trying to blow it off as not a big deal, "you were asking for this!" and all that. It should have been done differently, you know it should have. -Sergey -- http://self.maluke.com/ On 2 September 2011 01:33, Wesley C (Google) <wesc+...@google.com> wrote: > On Wed, Aug 31, 2011 at 10:23 PM, Srirangan <sriran...@gmail.com> wrote: >> >> The mode of operation seems to be: >> 1. Attract users with free / very low cost, cloud infrastructure >> 2. Force them to use Google specific APIs aka lock them in >> 3. Drastically increase prices giving users only a couple of weeks notice >> 4. Since they're locked in, and can't migrate their app in a couple of >> weeks, fleece them! >> I do hope somebody from Google tells me that I am wrong! :-) > > we understand what users are feeling, but i think you're mistaken on some of > your points: > 1. most Google products are free/low cost. App Engine was/is no > exception. it was/is also in it's beta or preview period... a time for users > to "try before you buy." however, unlike a standard API, this is a > distributed application execution platform, which is not exactly a low-cost > service. > many users are comparing App Engine to EC2, but that is not an accurate > comparison... yes, both are fruits, but this is really apples vs. oranges. > with EC2, *you* have to not only worry about your app, but also *everything > else*, like elasticity/scale, operating system, database server, web server, > load balancer, licenses, patches/upgrades, etc. i would argue that > scalability is the most difficult and most expensive thing to build on your > own. > your app can be slashdotted or tweeted by demi moore > -- http://adtmag.com/blogs/watersworks/2010/10/mobile-app-creators-talk-google-app-engine.aspx > -- or perhaps you may need to build/host something on the scale of both the > royal wedding blog and event livestream with traffic numbers that are > mindblowing > -- http://googleappengine.blogspot.com/2011/05/royal-wedding-bells-in-cloud.html > ... *these* are the reasons for using App Engine. it was not meant as > free/cheap generic app-hosting but to provide a premium service that's > difficult to get elsewhere in the market. if you're just after the former, > there are plenty of options for you. > 2. this is directly related to #1. the company has spent many years and $$$ > to build infrastructure that is "Google-scale," whatever you think that > means, and you should have an idea. we've built a system that lets you > leverage all the research and horsepower, but because it's all hand-built, > you need to use our APIs to take advantage of it! after all, you can't get > something for nothing, or can you? perhaps you *can*, if you're developing a > Django app using Python. > the Django web framework traditionally relies on a SQL/relational DB, but > the django-nonrel project -- http://allbuttonspressed.com -- enables Django > apps to run on NoSQL/non-relational databases, including MongoDB and App > Engine. (ports to Cassandra, Redis, SimpleDB, etc., are also underway.) what > this means is that you can write a traditional Django app but can choose > *where* you want to run it, whether it be on App Engine, or via traditional > hosting (SQL or non). "lock-in" doesn't exist if you can move your app (and > data) to/from App Engine any time you wish with just a change of your > settings.py file! i've even written an article to help you port your app > from webapp to Django if you wish > -- http://code.google.com/appengine/articles/django-nonrel.html > that's on the client side as both the App Engine SDK as well as Django are > both open sourced. if you wish to run you own App Engine-like *backend* > compatible with the App Engine SDK & API, you can take a look at the > TyphoonAE -- http://code.google.com/p/typhoonae -- and AppScale -- > http://appscale.cs.ucsb.edu -- projects. Google welcomes/supports such > server-side projects -- http://appscale.cs.ucsb.edu/sponsors.html -- even if > we can't release our proprietary backend. in fact, one of the AppScale team > members has written about the project -- > http://googleappengine.blogspot.com/2010/10/research-project-appscale-at-university.html > -- and has interned here at Google! > 3. the price changes are a reflection of certain key facts: > a. Google as a company backing the entire platform as a product... instead > of being cancelled, we're coming out of preview mode and become an official > product! Google is not a non-profit company and cannot continue to operate > services at a loss. our products, and my paycheck's gotta come from > *some*where! coming out of preview means Google is committed to App Engine, > and in turn, we're committed to our users. > b. this service costs the company significant resources... premium services > like App Engine and YouTube require a lot of hardware and networking > bandwidth. We serve more than 1.5 *billion* pages views a day across all > applications! > c. we're adding an SLA and paid support -- > http://code.google.com/appengine/sla.html plus a business-oriented ToS -- > http://code.google.com/appengine/updated_terms.html -- with updates like > alternative billing options. These help prove to enterprise that we mean > business and provide a strongly-desired comfort level from larger customers. > d. most importantly, these changes were announced publicly during the second > week of May during Google I/O -- > see http://googleappengine.blogspot.com/2011/05/year-ahead-for-google-app-engine.html > ... slightly more than a few weeks notice. > 4. this is certainly not the intention, as stated above. We written up a FAQ > -- http://code.google.com/appengine/kb/postpreviewpricing.html -- as well as > provided guidance on adjustments that you can make to ease the transition to > the new pricing model > -- http://code.google.com/appengine/articles/managing-resources.html > we will continue to work with users over the coming months to help them with > any questions or concerns they may have. please reach out > to appengine_updated_pric...@google.com to send in your feedback and > concerns. > hope this helps clear up some details, > -- wesley > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > "Core Python Programming", Prentice Hall, (c)2007,2001 > "Python Fundamentals", Prentice Hall, (c)2009 > http://corepython.com > > wesley.chun : wesc+api at google.com : @wescpy > developer relations :: google cloud products > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > 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 google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
