Now that GAE starts charging by instance-hours, however they are calculated, the drive to optimize is significantly reduced: I no longer have to worry about a web app's CPU usage if I have to wait for I/O anyway.
Some will say that's how we, as developers, should allocate our time to improve productivity, but the cloud platform as a whole just becomes a lot more wasteful.
And this change makes GAE much less appealing than AWS. If I'm gonna pay for instance-hours anyway, why not just launch some EC2 instances and kill them when I don't need them anymore? Sure it comes with admin costs, but at least I can migrate to another cloud provider much easier. Judging from the comments on this thread, migrating away from GAE seems very expensive, if possible at all.
0.02 cpu-hours => 2.8 instance-hours
The only way this can possibly make sense is if they do the EC2 thing of "any part of an hour is billed as an hour", in which case, I might as well go with EC2.
Now, sure, when I'm using just a single instance, GAE is a nice way to get a webserver, a database, memcache, etc all set up and ready to go for a reasonable price. But if my business takes off, and I have enough traffic for multiple servers, and auto-scaling front-ends, etc, I'll be better off moving to EC2 or Rackspace.
Someone should start making this.
Yes, but don't they do this by running everything as CGI scripts? That won't perform well.
Big consumers of memory tend to be caching layer, which could (should, actually) run on different machines and bill based on memory usage.
I have to admit scheduling CPU and memory is an issue, but that shouldn't be the excuse to adopt a model that discourage optimizing for CPU usage.
The new pricing model charges are based on the number of instances you have running. This is largely dictated by the App Engine Scheduler, but for Python we will not be supporting concurrent requests until Python 2.7 is live. Because of this, and to allow all developers to adjust to concurrent requests, we have reduced the price of all Frontend Instance Hours by 50% until November 20th.
Our app (python runtime) is going from about $9 a month to projected $270 a month, almost entirely due to frontend instance hours. I have to think that once python 2.7 is live and concurrent users != concurrent frontends, this will get waaay more reasonable.
"""The Frontend Instance costs reflect a 50% price reduction active until November 20th, 2011. Learn more about the price reduction and ways to reduce your costs permanently."""
So come winter, I'm looking at > $500 a month... here's hoping concurrent requests on the python runtime will make a huge difference, otherwise, sheesh.
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.
This is a bait-and-switch, plain and simple.
Are you doing the "any part of an hour is billed as an hour" thing that EC2/Azure do?
That would be extremely useful to understand the new pricing scheme better.
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.
Google is charging per datastore operation, and last I saw was defining each entity returned as an operation.
If you were building a social network or twitter clone using the techniques they recommend in this talk at GoogleIO: http://www.google.com/events/io/2009/sessions/BuildingScalab...
...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.
Is that an accurate assessment?
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.
Which, in my opinion, is insane.
It's not clear to me, yet, what impact the new 2.7 concurrency features will have.
With the new changes, API time doesn't count, so all you're left with is pure CPU time. Since a single instance can service one request while waiting for another's API to return, you're pretty much limited by the CPU time you use.
I hope to be proved right, anyway.
The difference is quite important. In AWS, you can spin up dozens of processes in an instance. In GAE, the instance is the process. If the process is idle waiting for IO, you are still being charged. Spinning up more processes mean more instances running and more are charged.
In that sense, GAE's $0.08 per process-instance-hour is quite expensive compared to AWS's $0.085 per machine-instance-hour. "Single-thread" Python process needs multiple processes to handle multiple web requests which counted as multiple GAE instance-hours while only a single AWS instance-hour.
While I suspect they won't make it a habit of raising the price from here on out, the more I thought about it the more I've come to the conclusion that it makes sense to go with providers that use more standardized software stacks (despite how great not having to sysadmin is and the easy deployment from Eclipse to GAE), because that way I can take advantage of future competition of providers. If I go with GAE the costs to switchover become greater and greater the longer I'm there... so while they may never jack the price UP on me, they'll have little incentive to bring the price down due to increased competition.
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.
I also now note that there's a "Contribute" link at the very bottom of your main site.
If I may make a couple other suggestions:
* Fixing the "Development Branch" link on your page (it's in the "Download" menu) which confusingly points to this totally inactive URL: https://code.launchpad.net/~cgb-cs/appscale/appscale
* 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.
also to fight vendor lock-in, Python developers can create Django apps then run them on App Engine using django-nonrel or on any traditional hosted stack supporting Django; or move between then w/minor (settings.py) changes; don't forget data migration as well.
If you're concerned, use Django-nonrel, it's been amazing so far. Otherwise, appscale sounds like a good alternative.
My cost is only increasing about 4x, but others in this thread are seeing 20-100x increases. Changes like this impact more than GAE -- this will make me hesitant to use any platform that I can't easily migrate away from.
Also, congrats on bugsense, I highly recommend it!
With the price increase and very harsh cut down on API free-quotas (plus the absence of long expected SSL on custom domains) GAE no longer seems a good option for me :/
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.
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.
I'm paying around $15 a month. With the new prices I would have to pay $450 a month.
Time to migrate :(
Any recommendations for a python hosting?
GAE: "Almost all applications will be billed more under the new pricing"
"Infinite, automatic scaling" is a double-edged sword given the pricing model. Virtually anyone using GAE should be putting very finite caps on their resource usage lest they get a sudden spike of hn/reddit/whatever traffic that results in a usage bill that matches up with the "infinite" scaling GAE did for you.
That's obviously not something to be happy about but then again an argument can be made that the introductory free quota that Google gave was very generous.
This might give Go a push - as I understand it Go is the most efficient of the supported languages which should translate into less CPU hours => less money. On the other hand, other than template parsing/substitution, my code doesn't do any CPU intensive tasks. On the other hand, the CPU hrs might count the overall overhead of the platform, which for statically linked Go will be the smallest (both Python and Java have sizable runtimes that need to be initialized at startup - according to http://www.youtube.com/watch?v=HQtLRqqB-Kk, Java runtime is especially bad in that regard (this is towards the end of the talk in the q&a part).
Seems to me Google is competing in areas it'll never be really good at like social networks instead of using its core competency of running the world's biggest server farm.
The cost of my app is going from $9 per month to $200 per month. This is ridiculous...
You can still use a free instance that is 6.5 hours a day, 1 gig of datastore, 1 gig each of incoming and outgoing bandwidth, etc. Low volume sites should easily be able to stay in the free zone.
Free instances had better have a low loading request time (e.g., for Java apps, use Objectify instead of JPA, etc.).
Assuming I understand the new billing correctly, I can get a paid plan for $9/month + $36/month for one reserved always on instance. I also get 24 hours/day of free on demand front end instances to handle a bit more traffic.
I think that a paid for plan still gets the other free quotas of a free plan and you pay each day for any use over each free limit. Is this right? It looks like you can have 1 always on FE instance, and 1 or 2 on demand FE instances, and a reasonable about of resource use for less than a $100/month.
I'd love to use GAE for the reproduceability of dev environment, but lock in, 10x+ price increases and a VERY obtuse (not honest) explanations of how pricing is measured and billed makes EC2 look much better. I'll need EC2 anyway since you can't run arbitrary binaries (ie: PDF conversion) on GAE.
$9/app/month means that it doesn't really make sense for tiny hobby sites any more: it is comparable in cost to a tiny VPS host, and my VPS currently handles 19 domains.
The place where GAE makes most sense is the 'line of business' app that is basically just a set of forms backed by a database. Those kind of apps don't have any complex things going on that are going to require integration with existing code or custom server configuration: both places where the current crop of PaaS offerings risky right now.
Line of business apps currently require lots of manual labour from DBAs and IS, so paying $9/month to run the HR application is going to be a pretty good deal.
I guess the problem of really efficient web serving remains unsolved.
I'd imagine that the majority of the people on GAE have found that they don't actually need to scale as much as they thought when they signed up to it.
1)Usage based pricing, 2) Infinitely scalable and 3) an SLA
If you were building a social network or twitter clone using the techniques they recommend in this talk:
...you could easily pull back a hundred entities each time you pull someone's feed. It'd cost you a buck for every hundred pageviews or so.
That's really too much.
Telling us that Python 2.7 may reduce the cost multiplication factor by a bit just isn't very helpful.
Additionally, it also makes Google look a little bit stupid. We're supposed to accept that a world-leading company in the field of data processing, storage and server farms weren't able to determine ballpark running costs for their selling off their excess machine hours until now? Pfff.
In light of the fact that GAE hasn't exactly been the most stable platform, technical support has been untimely and poor, high priority bugs can stay acknowledged for years, a timeline for SSL support is still non-existant, and full search capabilities are only now impending at some unknown date (and how much will that cost when it finally arrives?), it really does make them look like rank amateurs.
The AWS team must be laughing.
That is, unless I got something very wrong, in which case we're all screwed.
This basically punishes IO/network bound apps and favors CPU-intensive apps.
I can see why some of the web apps has 100X cost increase since they spin up a process to handle a web request which can take fair amount of network time but uses very little CPU.
The new pricing model is not web-app friendly but favors heavy CPU-intensive backend processing kind of apps.
This blog post from today says at the end: "[...]and we hope you find these tools useful as we get closer to our goal of leaving preview!"
They just rolled out the new pricing.
The scariest part of looking at my billing history is "Frontend Instance Hour costs reflect a 50% price reduction active until November 20th, 2011"
I will be moving my app, if anyone else likes to use a freelancer, please drop me a line: firstname.lastname@example.org
The new free limit for frontends is 24 CPU hours, or 1 instance. I was seeing my frontend time in the 25-30 hour range each day.
Is the price increase still tenfold, or something more acceptable?
The essence of your data is saved. Nothing to worry about then..
And regarding the pricing... We'll see.. I'm not sure WHEN exactly it's going to be shifted - does anyone know?
And don't forget to look into what may be able to be done to minimize some of the quota impact. Good design changes may be able to have a noticeable positive effect there.
Have a look at AppScale if you are looking at moving off the platform. That may be a way to get 80% of the way there with less monumental changes.
You mean concurrency? That won't be available until November. And if it fails to save the bill, you'll be screwed big time.