Heh. TL;DR version - Google starts recovering their costs, hits people in unexpected places.
So back when I worked there Google had no clue what it cost to run their infrastructure at a fine grain level. Sure they knew the aggregate cost, that was easy, but knowing on an application level didn't exist. This was a problem since as more and more things were using the machines, how did you "bill" a department for their machine usage? That really crystallized when the bottom fell out in 2008 and suddenly there was going to be no more new machines/data centers for a while and everyone had to 'make do.'
They mobilized an effort to figure this out, its not like it isn't knowable, and ever the data driven company the first signs of light were appearing just as I was leaving. It should not be a surprise but they discovered many things they did not previously believe was true, and I don't doubt it has driven a lot of change going forward. One of the more interesting outcomes was that projects/products were actually getting cancelled if they cost more to run than they could generate in revenue (I'm looking at you Goog-411)
So this knowledge is being applied to GAE, which is great, its also another way to back compute some of their operational efficiencies.
But that it costs money to run stuff? Well that isn't really news is it? That it costs that much? Well there is the whole if it doesn't make money it will get cancelled threat.
And the kicker is pricing out the scarce resource. It looks (and I've been gone over a year and half so I am speculating based on this move on their part) like their 'scarce' resource is web server front ends. (the labeled "Frontend instance") Traditionally they've been like most multi-tier web properties split between front end machines which host the web facing stuff, and back end machines that do the heaving lifting and storing. And by this change one can reason that residency on the 'front end' is more valuable than crunching in the 'back end.'
I'm guessing PlusFeed gets a lot of web traffic. So they spend a lot of time 'actively' on the front side, and from their numbers they do practically nothing on the back side. This fits well with the sudden massive price increase.
This gives you an insight into Google's business dynamics as well. Where page-views are the limiting resource, and computation is not. When you look at it that way, you can see that most of their 'revenue' has to be delivered through their front end services, and so consuming that resource reduces (potentially) their income. Hence the charge inconsistency.
Now contrast that to Billy-Bob's Web Farm (fictitious service) where every machine in their data center can be a web server, and front end serving is trivial, its all about the bandwidth. Their pricing would probably be more gigabytes transferred.
I would not be surprised at all if it is impractical to run such 'translation' services (basically all web traffic very little compute) on a hosted environment like Google's.
I, and many others, spent a lot of time figuring out how to write apps that do it the "app engine way":
* Fast completes (30 second timeout)
* Offloading to task queues when you cant
* Channels
* Blobstore two-phase upload urls
* Mail eccentricities
We did so, because we believe Google when they told us If you write your apps in this really weird way then we will be able to give you scale and cost benefits that you wont be able to get elsewhere
We believed them, because it seemed reasonable. We laughed at those who complained that django would hit the 30-second limit: "Its not a general hosting! Figure out the App Engine way!" And we educated on how to do it right, and many were happy.
Well, it turns out that it is general purpose hosting, with all of the costs, and yet also with all of the (once rational, now bullshit) idiosyncrasies.
---
But that's not the biggest complaint. The biggest complaint is that when my friends and peers objected to App Engine, its strange requirements and its potential lock in, they were right and I am a fucking naive idiot. And I really don't like to be proven a naive idiot. I put my faith in Google's engineers and they have utterly destroyed my credibility. THIS more than anything is the cost to me.
Amen bro. The biggest frustration was we followed Google's preaching and spent lots of time to fit our apps to their restricted model, then have them turned around to destroy it. I don't have faith to do another round of optimization to fit their new restricted model. What is stopping them to change the ground rule again. I rather spend time to develop to a generic model that I have more control.
I'd recommend GAE to people who are prototyping - it's easy to do simple stuff in.
But mostly, GAE doesn't make sense for larger apps. You can't buy your way out of trouble, by putting your db on a dedicated server with fast drives and tonnes of RAM. You can't really use relational data without performance and reliability issues.
It's not just about the "app engine way". It's not like learning C or Haskell, and having to find a new way to write the code. You fundamentally cannot do big ad-hoc database operations.
And consider this - it was July last year that they introduced the MapperAPI. Before then, I don't think you could do Map-Reduce without manually re-implementing it yourself (on top of the cantankerous Appengine Datastore). Just think about that for a minute - how were you meant to do stuff the Appengine way without map-reduce?
Anyway, I don't think your credibility was "utterly destroyed". It was really hard to know whether or not the learning curve was worth climbing until you had tried. You just had to judge the book by its cover, and the "Google" brand is pretty compelling to an engineer. It's not the first time someone has been fooled into buying something because the provider has a good reputation.
From what else I've read, it sounds like engineers who didn't also wear green eye-shades (or good enough ones, or who didn't possesses or use good enough crystal balls) set up this debacle. And it was people wearing green eye-shades (who we can sincerely hope are also engineers) who aligned it with reality. Causing way too many people way too much pain.
Object lesson: if you're going to sell a service for cash money to others, paying close attention to your costs from the very beginning is not optional.
Yeah to me this decision is either an admission that the idea of hosted apps is a failure or that the people making the decisions at google don't understand app engine.
I'm on the App Engine team, and I just wanted to clarify one thing: The main difference between CPU hours and Instance hours is that CPU hours are charged based on CPU usage, while instance hours are based on wallclock time. The high ratio between the two you can see with PlusFeed is because it's spending a lot of time to serve each request, most of which is spent doing nothing - likely because it's doing outgoing HTTP requests.
Previously, we had no way to account for apps like this, that take a lot of wallclock time but very little CPU time, and as a result we couldn't scale them well. Under the new model, the charges reflect the real cost here - memory pressure. Every second an instance sits around waiting is a second that the memory occupied by that instance can't be used to serve other requests.
As others have pointed out, we're in the process of launching Python 2.7 support - it's currently in Trusted Tester phase - which will support multiple concurrent requests, and services like PlusFeed are likely to be able to take great advantage of that, reducing their instance hours by a large factor. Likewise, doing asynchronous URLFetches (where that's practical) can cut a huge amount off instance time.
First of all, thank you for chiming in, here, on HN. Your presence might also be welcomed on the google forum, since I've read most of the posts there and no one has managed to answer this question.
If memory pressure is the issue, how are the trusted testers finding their memory pressure when they have a whole number of in-flight requests? If the PlusFeed fellow got 2.7 working, we'd expect to see 100/3.5%= 28 in-flight requests. Do you have data on how big the base memory vs per-thread memory requirements of these apps are? Python isn't famous for freeing up memory.
Which is to say, do you have any solid numbers that tell us that when we switch to 2.7, you wont have exactly the same memory pressure and either have to up the instance-hour cost, or start charging for ram, or just limit in-flight request to 3 or 4 so that our costs are only 5 times as much instead of 20?
Bottom line: what we all woke up to is that fact that as of right now:
* you set the price of an instance, and
* you get to decide how many instances I'm going to pay you for
Some of us are thinking that while that was a great idea when engineers were in charge, its not such a great idea now the bean-counters have taken over.
What's most interesting to me about this article is that the management of GAE seems to actually be getting worse over time.
GAE has always had two main disadvantages. First, there is vendor lock-in because you code specifically to the data store, worker API, and so on (though arguably there are alternative platforms that implement the GAE API). Second, you cannot run custom code (custom C in some virtual machine) or have a custom architecture (if, say, Redis might be useful to have around). These disadvantages probably aren't changing and are probably necessary for auto-scaling, security of Google's infrastructure, and so on.
However, there are lots of little things that GAE has been getting wrong for a while that are totally unnecessary. Lack of hosted SQL support. Lack of SSL for custom domains. Just little things that are probably annoying to implement and boring, but totally necessary for real websites or websites just gaining traction. (I know these are in varying stages of early support at the moment.)
But now, the GAE team almost seems to want to actively disappoint users. With hosted SQL being a request for years, Guido appears to have spent a bunch of time re-architecting the API for the datastore instead. With this pricing increase, they're pushing the many developers who came to their platform based on price (due to the very interesting scaling properties of the Google front-end) off the platform.
Yeah, the hard limitation to request duration is pretty nasty too. It's a pretty limited platform overall, and never took aoff, so maybe they are trying to push people off it so they can eventually sunset it?
I love using GAE and got 8 apps running currently. At first the new pricing model shocked me. But please take a 2nd look. Sure it's more expensive than the old model. But you can set the maximum number of idle instances in your Application Settings page. Just set it down so no more that X instances get spun up:
> The Idle Instances slider allows you to control the number of idle instances available to your application at any given time. Idle Instances are pre-loaded with your application code, so when a new Instance is needed, it can serve traffic immediately. You will not be charged for instances over the specified maximum. A smaller number of idle Instances means your application costs less to run, but may encounter more startup latency during load spikes.
There is another setting for latency:
> The Pending Latency slider controls how long requests spend in the pending queue before being served by an Instance. If the minimum pending latency is high App Engine will allow requests to wait rather than start new Instances to process them. This can reduce the number of instance hours your application uses, but can result in more user-visible latency.
So if you are fine with a little higher latency for your app then you can reduce your bill by a great deal. If you want all that GAE can offer with max. instances available and lowest latency you gotta pay - as you would when you run n instances at another cloud provider.
The problem is the price, though. Spinning up a couple EC2 micro instances to run your app is $0.02/hr per instance and you can run a few threads per instance. Appengine is $0.04/hr (double that soon), with one thread per instance.
Thanks for the info. Is there a setting for max number of simultaneous instances? If your app gets slashdotted are your potential costs completely unbounded?
I think Google just doesn't really get how unique GAE was. It was a fantastic platform for small apps, and inevitable some percentage of these would grow to big, paying apps.
Also (sorry for the armchair quarterbacking here, can't resist..) it was exactly what Google can do better than anyone - best server infrastructure + Guido Van Rossums - while stuff like Google+ is exactly what Google haven't a clue how to do.
This is amazing. You've hit the nail on the head. Google would be much more successful if it focused on being Google and didn't try to be Apple+Fecaebook+X companies all in one.
An alternate perspective: Google App Engine is still a fine platform even with the new price increases. (Which they told us were coming by the way)
And by the time the pricing takes effect the updated python runtime should bring costs down even more.
The instance costs are comperable to Heroku AND you get a high availability data store AND the ability to store really huge amounts of data in the blobstore AND a CDN for serving images from said blobstore. Not to mention background processes, task queue, XMPP, memcache, Multitenancy and multiple versions of apps so you can easily roll things back or test out updates painlessly.
Try and replicate that setup on Heroku or AWS for anywhere near the costs and time that you can get there with app engine.
While you're fighting with AWS and playing sysadmin or trying to think of ways to bring down the costs of Heroku's database services by using RDS instead or being nickel and dimed by add-on fees I'll be shipping code. Code that actually takes advantage of the platforms strengths.
The blobstore is basically S3, and the CDN for the blobstore is basically CloudFront. Both S3 and CF seem to me to have really simple APIs, plugins to Rails and other common frameworks, and are almost certainly battle tested by an order of magnitude more companies than the blobstore. What am I missing?
As far as I can tell, of your list, Heroku has all of the things you describe, with the possible exception of XMPP. Task queues (workers, SimpleWorker), many flavors of high availability data stores, memcache (or even better, Redis as a service), multitenancy, multiple versions of apps (git, releases).
Is there something bad about RDS that I don't know about? I had always assumed you just spun it up and could optionally replicate a MySQL instance a few times in different zones.
More broadly, it sounds like you had a really bad experience with Heroku. If so, what was it? I'm a bit curious because we are rather dependent on it.
"An alternate perspective: Google App Engine is still a fine platform even with the new price increases."
This depends a lot on what you're doing. GAE is now pretty terrible if you're using it for high-bandwidth applications (say, a data proxy or similar). Especially when you compare it to other providers for whom bandwidth prices have been dropping (AWS, Linode, etc now offer incoming bandwidth totally free and the rates on outgoing are very low as well). If you're using it as a number-crunching backend with relatively small in/out datasets, the new prices aren't too bad at all.
"your app can be slashdotted or tweeted by demi moore -- http://adtmag.com/blogs/watersworks/2010/10/mobile-app-creat... -- 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-be... ... 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."
My take-away is that GAE is hard to justify unless your usage pattern is unpredictable and spike-y. I'm taking the long weekend to give dotcloud a serious test-drive.
The strength of GAE is the magic scaling beans, but to take advantage of it you need to lock yourself in massively. It's probably not realistic to port an existing application that actually needs real scale to GAE given the complexity of most apps by the time they reach that point. Therefore, the key funnel for them is new apps with hopes of becoming truly massive. Fortunately for Google way more people dream of scaling than actually will, but they need to A) not scare poor startups away with the price today and B) not scare them that they're going to get bent over and raped on price changes later.
Personally I'll never touch GAE with a 10' pole simply because of the support issue and perpetual-beta-culture uncertainties.
We tried to use GAE several times on our heavy traffic production, and was just too slow. We contacted google several times, but never received any help from them. So, thanks to this, we don't use them and we are not affected but the price change.
That's unreasonably expensive. For $68.46 he payed for a day you can have an "el-cheapo" dedicated box or a great VPS for a month. I still don't understand why people trade a bit of system administration and superb performance for a vendor lock and insane prices.
But it's 880 instance-hours per day. So assuming that "el-cheapo" dedicated box has similar performance characteristics to one GAE instance, then you'd need 37 of those boxes.
My question is why the heck 31.42 CPU hours turned into 880 frontend instance hours, and whether this is something a lot of other GAE apps are seeing as well.
Yeah I still don't understand why the Khan Academy and other educational/open source developers are using Google App Engine when it suffers from vendor lock-in.
some of it yes, but if you write modular code then its a none issue. Doing Java development, GAE supports most Java EE and popular frameworks, so if done correctly porting would not be an issue. I can't say the same about Python stack.
Our charges are going to be increasing from $0/day to $5-11/day. While bearable, it's a serious problem given so little notice, and disappointing since we invested in their infrastructure & optimized for their previous pricing plan. This is a serious hit for a bootstrapped startup getting off the ground. No doubt it will kill a lot of startups.
The problem is that google count each process of the python runtime as a separate instance and count them when they run only partial hours (amazon counts this way too, but you can run many, many python programs at the same time even on a micro instance).
My understanding of all these GAE pricing story is that Google decided that GAE is not a strategic business and that business unit need to break even or they will be canceled. Does this make sense?
If that were the case, wouldn't apps like google calendar get cancelled long time ago? I doubt the ads on google calendar are sufficient to sustain the number of users it has on a daily basis.
I'm wondering if google is just trying to encourage an architecture which is less bad for their site.
I'm guessing a small minority of apps were doing things in a way that was eating up tons more resources than they were paying for. I bet for many apps, this could end up no worse or better.
I don't think it's a small minority of apps. 100% of the people I know who are using GAE are seeing the minimum of a 4x price increase for their app (before the 50% discount). The price increase would actually prevent some small ISVs from reaching ramen profitability. There's a thread somewhere on the GAE google groups containing many angry users.
It sounds to me like the scarce resource was found to be RAM, not CPU. If an "instance" uses a big piece of RAM to serve a request, and doesn't give it up while waiting for a backend, then scalability is RAM-bound, not CPU-bound, and they should probably charge that way.
The $2.63 a day comes out to $81 a month which for hosting is a non trivial amount. It does come down to whether Google can turn a profit at these levels for someone using this amount of resources but I don't think customers willing to pay $50-$100 a month are ones you want to push away.
I've been playing with ep.io for a while (nothing serious), it's a standard Python + PostgreSQL stack using few inis for configuration. Their pricing is a bit high on bandwidth though, so I'll probably wait for Heroku Cedar to officially support Python and use that instead.
In my mind, the problem is not so much the extreme pricing difference, but the change in what's being measured, so not only is there a price increase, but it's nearly impossible to figure out how to compare the old vs. new schemes vs. competitors.
The huge price jump is a serious problem, but the weird metrics switch makes it feel like such a bait and switch. I'm going to be highly surprised if this isn't challenged in court.
[+] [-] ChuckMcM|14 years ago|reply
So back when I worked there Google had no clue what it cost to run their infrastructure at a fine grain level. Sure they knew the aggregate cost, that was easy, but knowing on an application level didn't exist. This was a problem since as more and more things were using the machines, how did you "bill" a department for their machine usage? That really crystallized when the bottom fell out in 2008 and suddenly there was going to be no more new machines/data centers for a while and everyone had to 'make do.'
They mobilized an effort to figure this out, its not like it isn't knowable, and ever the data driven company the first signs of light were appearing just as I was leaving. It should not be a surprise but they discovered many things they did not previously believe was true, and I don't doubt it has driven a lot of change going forward. One of the more interesting outcomes was that projects/products were actually getting cancelled if they cost more to run than they could generate in revenue (I'm looking at you Goog-411)
So this knowledge is being applied to GAE, which is great, its also another way to back compute some of their operational efficiencies.
But that it costs money to run stuff? Well that isn't really news is it? That it costs that much? Well there is the whole if it doesn't make money it will get cancelled threat.
And the kicker is pricing out the scarce resource. It looks (and I've been gone over a year and half so I am speculating based on this move on their part) like their 'scarce' resource is web server front ends. (the labeled "Frontend instance") Traditionally they've been like most multi-tier web properties split between front end machines which host the web facing stuff, and back end machines that do the heaving lifting and storing. And by this change one can reason that residency on the 'front end' is more valuable than crunching in the 'back end.'
I'm guessing PlusFeed gets a lot of web traffic. So they spend a lot of time 'actively' on the front side, and from their numbers they do practically nothing on the back side. This fits well with the sudden massive price increase.
This gives you an insight into Google's business dynamics as well. Where page-views are the limiting resource, and computation is not. When you look at it that way, you can see that most of their 'revenue' has to be delivered through their front end services, and so consuming that resource reduces (potentially) their income. Hence the charge inconsistency.
Now contrast that to Billy-Bob's Web Farm (fictitious service) where every machine in their data center can be a web server, and front end serving is trivial, its all about the bandwidth. Their pricing would probably be more gigabytes transferred.
I would not be surprised at all if it is impractical to run such 'translation' services (basically all web traffic very little compute) on a hosted environment like Google's.
[+] [-] buff-a|14 years ago|reply
I, and many others, spent a lot of time figuring out how to write apps that do it the "app engine way":
We did so, because we believe Google when they told us If you write your apps in this really weird way then we will be able to give you scale and cost benefits that you wont be able to get elsewhereWe believed them, because it seemed reasonable. We laughed at those who complained that django would hit the 30-second limit: "Its not a general hosting! Figure out the App Engine way!" And we educated on how to do it right, and many were happy.
Well, it turns out that it is general purpose hosting, with all of the costs, and yet also with all of the (once rational, now bullshit) idiosyncrasies.
---
But that's not the biggest complaint. The biggest complaint is that when my friends and peers objected to App Engine, its strange requirements and its potential lock in, they were right and I am a fucking naive idiot. And I really don't like to be proven a naive idiot. I put my faith in Google's engineers and they have utterly destroyed my credibility. THIS more than anything is the cost to me.
[+] [-] ww520|14 years ago|reply
[+] [-] wisty|14 years ago|reply
But mostly, GAE doesn't make sense for larger apps. You can't buy your way out of trouble, by putting your db on a dedicated server with fast drives and tonnes of RAM. You can't really use relational data without performance and reliability issues.
It's not just about the "app engine way". It's not like learning C or Haskell, and having to find a new way to write the code. You fundamentally cannot do big ad-hoc database operations.
And consider this - it was July last year that they introduced the MapperAPI. Before then, I don't think you could do Map-Reduce without manually re-implementing it yourself (on top of the cantankerous Appengine Datastore). Just think about that for a minute - how were you meant to do stuff the Appengine way without map-reduce?
Anyway, I don't think your credibility was "utterly destroyed". It was really hard to know whether or not the learning curve was worth climbing until you had tried. You just had to judge the book by its cover, and the "Google" brand is pretty compelling to an engineer. It's not the first time someone has been fooled into buying something because the provider has a good reputation.
[+] [-] ja27|14 years ago|reply
Come to a Microsoft event some time and let a Silverlight developer buy you a sympathy beer.
[+] [-] hga|14 years ago|reply
From what else I've read, it sounds like engineers who didn't also wear green eye-shades (or good enough ones, or who didn't possesses or use good enough crystal balls) set up this debacle. And it was people wearing green eye-shades (who we can sincerely hope are also engineers) who aligned it with reality. Causing way too many people way too much pain.
Object lesson: if you're going to sell a service for cash money to others, paying close attention to your costs from the very beginning is not optional.
[+] [-] greendestiny|14 years ago|reply
[+] [-] nicksdjohnson|14 years ago|reply
I'm on the App Engine team, and I just wanted to clarify one thing: The main difference between CPU hours and Instance hours is that CPU hours are charged based on CPU usage, while instance hours are based on wallclock time. The high ratio between the two you can see with PlusFeed is because it's spending a lot of time to serve each request, most of which is spent doing nothing - likely because it's doing outgoing HTTP requests.
Previously, we had no way to account for apps like this, that take a lot of wallclock time but very little CPU time, and as a result we couldn't scale them well. Under the new model, the charges reflect the real cost here - memory pressure. Every second an instance sits around waiting is a second that the memory occupied by that instance can't be used to serve other requests.
As others have pointed out, we're in the process of launching Python 2.7 support - it's currently in Trusted Tester phase - which will support multiple concurrent requests, and services like PlusFeed are likely to be able to take great advantage of that, reducing their instance hours by a large factor. Likewise, doing asynchronous URLFetches (where that's practical) can cut a huge amount off instance time.
[+] [-] buff-a|14 years ago|reply
If memory pressure is the issue, how are the trusted testers finding their memory pressure when they have a whole number of in-flight requests? If the PlusFeed fellow got 2.7 working, we'd expect to see 100/3.5%= 28 in-flight requests. Do you have data on how big the base memory vs per-thread memory requirements of these apps are? Python isn't famous for freeing up memory.
Which is to say, do you have any solid numbers that tell us that when we switch to 2.7, you wont have exactly the same memory pressure and either have to up the instance-hour cost, or start charging for ram, or just limit in-flight request to 3 or 4 so that our costs are only 5 times as much instead of 20?
Bottom line: what we all woke up to is that fact that as of right now:
* you set the price of an instance, and
* you get to decide how many instances I'm going to pay you for
Some of us are thinking that while that was a great idea when engineers were in charge, its not such a great idea now the bean-counters have taken over.
[+] [-] pbh|14 years ago|reply
GAE has always had two main disadvantages. First, there is vendor lock-in because you code specifically to the data store, worker API, and so on (though arguably there are alternative platforms that implement the GAE API). Second, you cannot run custom code (custom C in some virtual machine) or have a custom architecture (if, say, Redis might be useful to have around). These disadvantages probably aren't changing and are probably necessary for auto-scaling, security of Google's infrastructure, and so on.
However, there are lots of little things that GAE has been getting wrong for a while that are totally unnecessary. Lack of hosted SQL support. Lack of SSL for custom domains. Just little things that are probably annoying to implement and boring, but totally necessary for real websites or websites just gaining traction. (I know these are in varying stages of early support at the moment.)
But now, the GAE team almost seems to want to actively disappoint users. With hosted SQL being a request for years, Guido appears to have spent a bunch of time re-architecting the API for the datastore instead. With this pricing increase, they're pushing the many developers who came to their platform based on price (due to the very interesting scaling properties of the Google front-end) off the platform.
Overall, I'm very confused.
[+] [-] mcantelon|14 years ago|reply
[+] [-] skybrian|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] Smrchy|14 years ago|reply
> The Idle Instances slider allows you to control the number of idle instances available to your application at any given time. Idle Instances are pre-loaded with your application code, so when a new Instance is needed, it can serve traffic immediately. You will not be charged for instances over the specified maximum. A smaller number of idle Instances means your application costs less to run, but may encounter more startup latency during load spikes.
There is another setting for latency:
> The Pending Latency slider controls how long requests spend in the pending queue before being served by an Instance. If the minimum pending latency is high App Engine will allow requests to wait rather than start new Instances to process them. This can reduce the number of instance hours your application uses, but can result in more user-visible latency.
So if you are fine with a little higher latency for your app then you can reduce your bill by a great deal. If you want all that GAE can offer with max. instances available and lowest latency you gotta pay - as you would when you run n instances at another cloud provider.
[+] [-] mtogo|14 years ago|reply
[+] [-] jcheng|14 years ago|reply
(Just out of curiosity, I'm not a GAE customer)
[+] [-] nir|14 years ago|reply
Also (sorry for the armchair quarterbacking here, can't resist..) it was exactly what Google can do better than anyone - best server infrastructure + Guido Van Rossums - while stuff like Google+ is exactly what Google haven't a clue how to do.
[+] [-] switch|14 years ago|reply
[+] [-] andymoe|14 years ago|reply
And by the time the pricing takes effect the updated python runtime should bring costs down even more.
The instance costs are comperable to Heroku AND you get a high availability data store AND the ability to store really huge amounts of data in the blobstore AND a CDN for serving images from said blobstore. Not to mention background processes, task queue, XMPP, memcache, Multitenancy and multiple versions of apps so you can easily roll things back or test out updates painlessly.
Try and replicate that setup on Heroku or AWS for anywhere near the costs and time that you can get there with app engine.
While you're fighting with AWS and playing sysadmin or trying to think of ways to bring down the costs of Heroku's database services by using RDS instead or being nickel and dimed by add-on fees I'll be shipping code. Code that actually takes advantage of the platforms strengths.
[+] [-] socratic|14 years ago|reply
The blobstore is basically S3, and the CDN for the blobstore is basically CloudFront. Both S3 and CF seem to me to have really simple APIs, plugins to Rails and other common frameworks, and are almost certainly battle tested by an order of magnitude more companies than the blobstore. What am I missing?
As far as I can tell, of your list, Heroku has all of the things you describe, with the possible exception of XMPP. Task queues (workers, SimpleWorker), many flavors of high availability data stores, memcache (or even better, Redis as a service), multitenancy, multiple versions of apps (git, releases).
Is there something bad about RDS that I don't know about? I had always assumed you just spun it up and could optionally replicate a MySQL instance a few times in different zones.
More broadly, it sounds like you had a really bad experience with Heroku. If so, what was it? I'm a bit curious because we are rather dependent on it.
[+] [-] georgemcbay|14 years ago|reply
This depends a lot on what you're doing. GAE is now pretty terrible if you're using it for high-bandwidth applications (say, a data proxy or similar). Especially when you compare it to other providers for whom bandwidth prices have been dropping (AWS, Linode, etc now offer incoming bandwidth totally free and the rates on outgoing are very low as well). If you're using it as a number-crunching backend with relatively small in/out datasets, the new prices aren't too bad at all.
[+] [-] maxent|14 years ago|reply
https://groups.google.com/d/msg/google-appengine/obfGjbIkOTI...
"your app can be slashdotted or tweeted by demi moore -- http://adtmag.com/blogs/watersworks/2010/10/mobile-app-creat... -- 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-be... ... 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."
My take-away is that GAE is hard to justify unless your usage pattern is unpredictable and spike-y. I'm taking the long weekend to give dotcloud a serious test-drive.
[+] [-] dasil003|14 years ago|reply
Personally I'll never touch GAE with a 10' pole simply because of the support issue and perpetual-beta-culture uncertainties.
[+] [-] ddon|14 years ago|reply
[+] [-] sasha-dv|14 years ago|reply
[+] [-] jcheng|14 years ago|reply
My question is why the heck 31.42 CPU hours turned into 880 frontend instance hours, and whether this is something a lot of other GAE apps are seeing as well.
[+] [-] ww520|14 years ago|reply
[+] [-] robryan|14 years ago|reply
[+] [-] edtechdev|14 years ago|reply
[+] [-] angryasian|14 years ago|reply
[+] [-] aaronf|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] cd34|14 years ago|reply
Someone needs to rethink their architecture.
[+] [-] tomjen3|14 years ago|reply
The problem is that google count each process of the python runtime as a separate instance and count them when they run only partial hours (amazon counts this way too, but you can run many, many python programs at the same time even on a micro instance).
[+] [-] trafficlight|14 years ago|reply
[+] [-] cHalgan|14 years ago|reply
[+] [-] catch23|14 years ago|reply
[+] [-] vessenes|14 years ago|reply
[+] [-] gte910h|14 years ago|reply
I'm guessing a small minority of apps were doing things in a way that was eating up tons more resources than they were paying for. I bet for many apps, this could end up no worse or better.
[+] [-] catch23|14 years ago|reply
[+] [-] buff-a|14 years ago|reply
[+] [-] herf|14 years ago|reply
[+] [-] kennystone|14 years ago|reply
[+] [-] robryan|14 years ago|reply
[+] [-] heliodor|14 years ago|reply
What are some good services layered on top of EC2 to provide more management and automation?
Does anyone have any experience with whether DotCloud is priced reasonably?
[+] [-] sirn|14 years ago|reply
[+] [-] bane|14 years ago|reply
The huge price jump is a serious problem, but the weird metrics switch makes it feel like such a bait and switch. I'm going to be highly surprised if this isn't challenged in court.