The single most import reason that I like GAE is that it used to charge based on CPU usage, so that I could carefully optimize my web apps to reduce costs. This is also why I think cloud computing is a good thing: shared resources are generally efficiently used.
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.
Indeed. The billing estimator they provide says that, on this one day, I was using 0.02 cpu-hours, and they estimate that under the new system that same activity will be billed as 2.8 instance-hour.
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.
Yes, this was my feeling too. The great thing about GAE was that you paid for CPU time, not CPUs. Which means that if I want to run something tiny I only pay for the tiny amount of CPU it uses.
Wouldn't the perfect cloud platform be one that charges based on disk IO, disk space used, network IO, RAM space used, (Ram IO?,) and CPU used? Maybe there are other metrics I'm ignoring.
https://www.nearlyfreespeech.net/services/pricing been around since 2002, does automatic load-balancing, have most of the benefits of what people are calling "cloud-computing", makes no presumptions about language of choice, does MySQL, and is extremely competitively priced.
I've certainly seen virtualization environments where RAM is a much larger fraction of the physical server's cost than the CPUs. How much RAM are you using when you aren't using many CPU cycles?
How much RAM does a web server need waiting for socket I/O? Not a lot. For most typical web apps, an instance of web frontend consumes a small fraction of the system's total memory. You could fit a surprisingly lot of such instances into a modern machine.
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 change means that it doesn't matter what you're waiting for. As long as you have an instance up, you are charged for it, even if it's not actually doing anything at that moment.
The multithreading change, though, will mean that a single instance will wait for multiple I/O calls to return. If these aren't charged, you'll only need to pay for that single instance and nothing more.
Unfortunately there's a limited number of threads to handle requests (like 8 per instance) and you can't create new long-lived threads. While an improvement, it's not a solution to the problem.
Supposedly it will change, but that's what's available in Python 2.7 preview. The number might be different on release, but I don't think the limit itself will be removed.
"""
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.
Oh shit, and the $270 a month is with the 50% discount:
"""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.
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?
If I was unable to get the multiplier down so that our ultimate hosting cost is < $200 a month, I'd probably switch. But we have revenue to cover the hosting cost, so then again, it would be a big deal to divert or limited eng resources (me and one other guy) towards a big migration project. I'm guessing our hosting costs would be at least $100 a month anywhere else, and I've grown fond of a lot of the services provided with app engine.
One of my clients, whose app sees a decent amount of traffic, is going to go from $510/month to $2070/month _if_ the 50% frontend discount is applied. After the discount lifts, it looks closer to $3300/month.
Which, in my opinion, is insane.
It's not clear to me, yet, what impact the new 2.7 concurrency features will have.
Without performance tuning, this will take my SharedCount API (http://sharedcount.com) from ~$0.50/month to $750 per month, post discount. Unless I can tune it significantly, I'll almost certainly have to shut the API down.
I am assuming (big, unfounded, no-data assumption here) that, with multithreading, instance-hours will roughly match CPU hours for most applications. Most apps take care to minimize actual request CPU usage, so most is in the API.
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 think it's unfortunate that GAE use the term instance-hour for billing, which is quite different from AWS instance-hour. GAE's instance-hour is process-instance-hour while AWS is machine-instance-hour.
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.
The trouble with App Engine is that I'm now locked in to their API. They can raise prices and I have no real recourse unless I want to rewrite a lot of code.
I was an early advocate of GAE but this is now my fear as well. When the new pricing was announced, the amount that they raised the service by seemed quite fair, but just the fact that it went up spooked me into being afraid of the fact that they could readjust the price at any time.
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.
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 can have the best of both worlds, Java has standardized their web format to the point where you simply upload a zip archive (if you don't want to work with Java, almost all frameworks for jvm languages, including lift, are compatible with the framework).
I'm not up to speed on how compatible and recent it is, but AppScale bills itself as "Open Source Platform for Google App Engine Apps": http://code.google.com/p/appscale/
in addition to AppScale also look at the TyphoonAE project... these are open versions of the App Engine backend that claim to be fully-compatible to the SDK/client-side.
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.
Not much familiar with GAE but how hard would it be to build an abstraction layer and have it deployed on, say, AWS or Rackspace, using HBase or Cassandra as backend?
The datastore API is probably the most involved for porting to. You would have to do both indexes and composite indexes for scalable queries, and implement your own transaction system. You can learn about how we do it for AppScale in our publications. Also check out the articles on the App Engine documentation, as well as the Google I/O videos for details on how they do it for Megastore/BigTable.
I have written multiple projects for GAE in Django and even ported one to it. The changes are seriously minimal. In the ported project, I had to change two lines of a lookup query that was a JOIN.
If you're concerned, use Django-nonrel, it's been amazing so far. Otherwise, appscale sounds like a good alternative.
If you're writing in Java, use standard API like JPA instead of native (that's what we're using with our site). I've tested some sample code on Amazon Beanstalk, and the code (with JPA) WORKED WITHOUT A SINGLE ALTERATION. It's not 100% obviously, e.g. if you use native types like Key, but the point is you CAN write your code to be compatible with any Java platform.
If Google had said from the beginning that their pricing was discounted for the preview, I would not have had a problem with this. But given that they didn't communicate this and that the cost of switching platforms is high, this feels more like a bait and switch tactic.
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.
We (at bugsense) have about 500k requests per day and some of the are very intensive. Currently we pay $5.40 daily and it will go up to $22. So per month with the old pricing we ll be at $162, with the new pricing we ll up to $660.
It's x4 increase and that makes it bit cheaper than EC2 for the same amount of data. If we subtract the administration cost it makes it cheaper.
The old, cheap days are gone :( But still it compares well in comparison to other popular cloud solutions.
Yes without but there is a lot of space for improvement with better leverage of taskqueues and async datastore operations. We hope to reduce by 50% some some of the requests so that we spin out less instances. We also fine tuned a bit, check out our results:
http://news.ycombinator.com/item?id=2951217
About the huge cost increase people mention in the comments: New cost unit is IH (Instance Hour) and GAE python scheduler has a habit of revving up new instances aggressively. To lower costs one needs to lower Max Idle Instances and -maybe depending on the situation- increase Min Pending Latency, thus lowering the Instance count (and the cost).
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 :/
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.
I think it's still in the works. They don't mention it, but Heroku Cedar will happily reads and install requirements as defined in requirements.txt when you push to it. Server setup is just a simple Procfile calling whatever Python web server you want to use.
ep.io is gaining ground with Django developers but it also runs other WSGI apps. I don't have personal experience with their pricing but the stack and services is starting to look pretty good at the moment. Heroku Cedar Stack and DotCloud might be other options.
Wow - According to their projections based on current usage, I'm seeing a 100x increase in my daily cost. I guess I will be migrating off of App Engine. I'm feeling pretty burned at this point.
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.
I've ported part of app build on top of gae to amazon and face huge difference in billing structure. I've been paying whole gae $4/month, while aws charged 10x. After these changes ... I have no alternatives left ...
Eh, if price is the largest factor in your decision, I would probably recommend Dreamhost over either of them. The real trouble is that GAE doesn't seem to offer a whole lot more than AWS.
I love the admin-free nature of GAE, that's why I started using it in the first place.
"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.
Well, in fact anyone should ensure a positive ROI for visits, otherwise no visit is cost-effective after the free tier. If you make more than you spend per visit, you don't need limits and the infinite scaling capability is a godsend.
I'm seeing going from $0 to around $1 per day (can be as low as $0.25), all of it for CPU hours. This can be seen in billing history.
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).
I don't think it's a matter of Python/Java being slow and GO is faster. It actually doesn't matter which language you pick. If your GO app is IO/network bound, you will be charged for the idle CPU hours in the new billing scheme.
You should also note that CPU hours turn into instance hours in the new pricing, but it's a straight conversion. With multithreading, the instances you use will go down, perhaps significantly. I believe they will about match your CPU hours, so you might see comparable pricing (if the price per instance hour is the same as the old CPU hour, anyway).
Very disappointing. GAE for a while was for developers what Tumblr/WP.com/etc are for writers, a way to put an idea online cheaply & easily. The generous quotas made using the proprietary APIs worth it. Now it's just another PaaS.
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.
I just read all of the comments and one thing that no one mentioned explicitly:
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 think that's the dumb part though. If you get one user per hour for 12 hours a day, you're still overflowing the "6.5 hour limit" (unless I'm misunderstanding everything).
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.
I would see this as a move towards 'enterprise' (yes I know people here hate that word), but look at the url...
$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 have one new app during design phase. The frontend part is going to be in GAE since I had done couple apps in GAE and familiar with it. A part of the backend will be in AWS because I need to run a custom 3rd party app. With the new pricing model, it doesn't make sense to run webapp in GAE. I'll redesign the thing to run the whole thing in AWS.
The source of my disappointment is that basically, they couldn't figure out how to slice and dice page serving without dumping you with the cost of a full VM. I was hoping they were committing to researching how to make that work, so if you made an efficient application you never had to worry about the infrastructure. Now, the abstractions have leaked and we have to worry about VM's. Time to update my answer here:
http://programmers.stackexchange.com/questions/64727/windows...
I guess the problem of really efficient web serving remains unsolved.
I just sent some mail to my old colleagues in Windows Azure. If you're working on a cloud provider, a large one or a startup, you and your biz-dev/sales team should be out there actively trying to get people dissatisfied with GAE's announcement today (and from what I hear, that is a significant number).
This pretty much confirms my reservations of investing in a closed stack. However, it's really a shame that Google didn't take the time to provide a clean migration path for people to take their apps out of the platform so they can scale up to a regular hosted or self-hosted application.
App Engine seems like a great platform, but unfortunately it's a pain in the ass to switch away if you decide you want to. Unless I'm building a small/quick app I do not want to be 'locked in' to App Engine.
Meanwhile, VPS and dedicated server providers are getting cheaper, faster and more competitive.
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.
The most disappointing thing for me was that the little bit of banner advertising I have on the games is no longer going to cover the cost of the hosting. It was nice a thought that the games could sit there forever and people could enjoy them for free.
It's obvious that there are many people who are upset about this price hike, how poorly it has been explained (showing "this is how much more we'll be charging you really soon!" side-by-side with the current pricing really doesn't help), and that it feels like a bait and switch given how AppEngine was originally sold on the basis of scaling against CPU usage rather than instance hours.
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.
I don't understand how the instance-hours are being calculated. One of my apps has the old 2.5 CPU-hours/day to the new 34 instance-hours/day calculation. The app is not CPU-intensive and 2.5 hours of work sound reasonable. It certainly is not hogging the CPU 34 hours the whole day. Does the new instance-hour include the process idle time of app?
They calculate how many minutes an instance is active and sum all that. If your application is network/API/I/O bound, you will get highly inflated counts. However, if you take multithreading into account, one instance of an I/O bound app should be able to serve many, many requests, so your usage will go down tenfold again.
That is, unless I got something very wrong, in which case we're all screwed.
So it counts idle time. When a process is idle, it doesn't use the CPU, which can be used by other processes.
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.
Not really, if you enable multi-threaded request handling. While one thread/request is waiting for IO/network to complete, other threads are still handling requests. All in the same instance.
After I read the email from Google, I didn't think the impact would be huge on my small app that just started gaining users, but it was a little shock, I headed to HN to find out if other people are affected or my app was badly written. I think everyone is affected.
I will be moving my app, if anyone else likes to use a freelancer, please drop me a line: varese4@gmail.com
If your app can survive on 1 instance, but occasionally uses 2 or more, you should immediately change your "max idle instances" to 1 so you won't be charged for the extra instances.
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.
Everyone is talking about huge cost increase for python applications, but I'd like to know what are the numbers for Java applications, since Java is multithreaded?
Is the price increase still tenfold, or something more acceptable?
This is a total bait and switch. On the same day that Appengine took our site down for 18 hours with no apology(we support 3000 daily visitors with an average time on site of 13 min). They announced that costs would increase from $240 per month to $6000. SIX THOUSAND! This is truly the definition of evil if you ask me.
It's not only about the data, however. It's also about the x lines of code that are GAE specific. The datastore API is non-standard, and cannot easily be ported elsewhere.
There has been a lot of confusion and complaining about the price increases, and this is understandable given the way it has come about. This is one of those oh so obvious things, but you just have to look at it and evaluate.
Besides scalability, app engine can be a great platform from a rapid app development standpoint. It has other nice aspects in addition to the scalability.
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.
"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."
You mean concurrency? That won't be available until November. And if it fails to save the bill, you'll be screwed big time.
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.