we've cut the free quotas from super-generous to just generous. we're still the only large service offer generic platform free quota with no time limit.
as for delay in SSL on custom domains, we're guilty as charged; we're not happy it's taking so long and we're working hard on it.
Costs for our app have just gone from $120 per month to $1200. Its a service we provide to users for free, we cant afford that level of hosting. That is a 10x price increase.
How many biz can get away with that sort of hike? This and how Google treats Android developers (shutting down forum, not responding to issues) is making me question why I bother building anything for your platforms.
I was on app engine from the start, I've sat though your DevFests, arranged hackathons, and told countless people they should use your platform. I've invested many hours learning your API. But this is it, its over, no more.
Anything but a tiny free app is going to cost the earth, if you want to scale use AWS or Heroku. If you are an outside developer trusting Google it will cost you.
some apps get high multiples because they're using resources that weren't counted before, or were counted differently; that's why we enabled side-by-side billing now (before we switch on billing). if you email me your appid (psm@google.com) we can help. you should also review the FAQ and the tuning tips web page that we put together.
we encourage you to look at appscale for app mobility. we're not interested in artificial lock-in from APIs. we're not that kind of a company. we're confident we can make the overall service superior. please note that we haven't changed the prices since we launched pricing, and GAE was in preview. that's an element to the notion of "preview". we're now taking it out of preview into a fully supported Google product. and part of that was to reprice so we have a sustainable business. after we announced the new pricing in May at I/O, we've actually seen our growth rate increase, since customers appreciate that we're committing to GAE.
They seem to do a rare (once a year or so) push of whatever they've developed into a public source repo, and then just leave it there. No updates, no bug fixes, no community involvement, etc.
Their site looks like they're trying to sell me something, but there's no commercial product in evidence. And the whole thing seems to be done under the auspices of a university.
There's a link to their supposed development branch, bizarrely on launchpad instead of Google Code where they seem largely based, but it's empty.
I'm not really inclined to put time and effort into something whose model and motivation completely escapes and/or scares me.
We're very much graduate students and our testing cycle takes a lot of time away from doing research and publishing papers. We try to keep the main branch as stable as possible though for those who just want to get the latest and greatest. Our branches are pretty active and we do track issues/bugs and fix them, although you're right that we don't do so on our Google Code page.
https://code.launchpad.net/~appscale-maintainers/appscale/ap...
* Making some sort of statement on the Google Code page about your development practices and the fact that the bleeding edge is on Launchpad. People like me go to a Google Code page expecting to see the development site, complete with an active source tree, and get very confused when that's not what it really is.
Don't take this the wrong way, but when you are presenting yourself as a representative for a company (when you are using "we" to mean Google) you may want to use proper capitalization and grammar otherwise it makes your company seem like a popsicle stand instead of a Fortune 500 company.
you have time before the billing switches on to tune/adjust your application. check out the FAQ and tuning tips page. the prices are going up, but they are also changing, in that we're measuring things differently. most apps that are initially seeing a large multiplier are because of the latter effect, not the former. this is why we built and launched the side-by-side billing. (i'm on the GAE team)
Out of curiosity, have you received any positive responses to the new pricing structure? When it was first announced, it was couched as something users were asking for (unbelievably) but I can count on one hand since that announcement I've seen comments that ran in favor of this.
For the kinds of multiples in increases being talked about, I'm hoping GAE also brings online some professional support people with a 24-hour turn around time. The only times we've been upset with GAE was the lousy support-via-web-form (a form with instructions that doesn't seem to address how we should communicate with the GAE team at all) when something wasn't going right on your end that directly cost us revenue.
I think the turn around on a response to our support problem took >2 weeks. It was successfully resolved, but it was an issue such that we were looking at having to essentially start our entire enterprise over from scratch if it wasn't taken care of.
Your "preview" felt a lot like GMail's "beta" did. You had fully released it and were evangelizing it, the only thing you've done now is removed the label and hiked up your pricing by an astounding amount.
Could you clarify how much the Python 2.7 multithreading feature would help I/O bound apps keep their instances down? My reasoning is that the instance/hours will roughly equal current CPU hours (rather than be the 4x, 10x and 100x we're seeing here), but do you have any actual data?
That would be extremely useful to understand the new pricing scheme better.
"for Python we will not be supporting concurrent requests until Python 2.7 is live"
Could I be guessing right in that this means no concurrancy at all within a given instance - so an instance chewing CPU time an instance blocked waiting for IO to complete are no different in this model.
...you could easily pull back a hundred entities each time you pull someone's feed. Each entry is a separate entity. It'd cost you a buck for every pageview.
Thanks, it's assuring to hear that tuning will likely reduce the price spike. Looking through the most requested handlers on our site, one that serves an embedded widget is currently not using memcache. I'm hoping tuning that handler alone will make a big difference.
Btw, a dashboard showing handlers sorted by average latency would be a big help! I can use appstats to get close to this, but given that the concurrent frontends are the dominant factor in pricing going forward, having it build in would be great.
Do you have a sense of how much tuning can reduce costs? We're looking at a ~7x jump in prices for a big app; might we be able to quarter that? Halve it?
