5 ms·

Any developer who was burned by App Engine pricing in the past is likely to take the lure of a "70% off" discount with a grain of salt because of the much highe

by branola 11y ago

Any developer who was burned by App Engine pricing in the past is likely to take the lure of a "70% off" discount with a grain of salt because of the much higher cost of incorrectly relying on Google's pricing pledges. In case anyone forgets, the pricing changes on Google App Engine caused many developers to abandon apps they had developed on the platform because of hundreds of percent increases in pricing: https://groups.google.com/forum/#!topic/google-appengine/rSh8mgw2f3c https://groups.google.com/forum/#!topic/google-appengine/rSh...

spankalee 11y ago
App Engine was in preview when its price changed.
- branola 11y ago
  It was in "preview" for 3 years. During those 3 years no warning was given that the pricing changes were going to be of such a magnitude. As a result people had sufficient time and not enough warning to build entire businesses on an infrastructure that they later had to abandon. That's unforgivable.
  - Alupis 11y ago
    > build entire businesses on an infrastructure that they later had to abandon. Frankly, if your business is built entirely around a single 3rd party provider, and you are totally incapable of pivoting cloud providers at short notice... well then you are "doing it wrong".
    - discardorama 11y ago
      Like Netflix? They seem to be doing alright.
      - Alupis 11y ago
        > Like Netflix? They seem to be doing alright. Could you elaborate a little? Netflix doesn't rely on a single provider for hardware, data centers, nor bandwidth. Sure they use EC2 for some things, but also have a great deal of hardware in data centers throughout the country, as well as custom hardware in ISP data centers, etc. I'd be shocked if there didn't use some of the other cloud provider offering too. Netflix has no single point of failure. Building your business around a single cloud provider creates a single point of failure.
    - justonepost 11y ago
      That's the point that was made above. Don't build anything that relies on this architecture unless you can migrate.
  - spankalee 11y ago
    The new pricing made it App Engine a sustainable business, because the old pricing model didn't actually account for costs and encouraged some very wasteful practices. The only other option to actually charging enough to cover costs would be to shut the service down. I'm sure more people would be more upset about that. App Engine has always been a unique PAAS because its APIs were designed to try to force developers into better distributed app architectures. The non-relational DB with entity groups and limited queries, the 30s request limit, originally not offering long-running instances, the task queue, memcache as a service, all made for scalable apps. But the costs unfortunately weren't designed the same way. Charging by CPU time, and having datastore access free was especially bad for a market where apps typically use very little CPU, but access data a lot. A lot of blog posts came shorty after the price change that said after making the recommended changes to datastore calls, and enabling multithreading that they got their bill down and performance up significantly. Many apps were doing absolutely no caching, or logging every request to the datastore, because datastore was ridiculously cheap for small records. Some were doing what should have been batch work per-request because they didn't use task queues. Since 2011, I think all price changes with Google Cloud have been price drops, some pretty big. Last year, App Engine prices were dropped 30%.
    - pekk 11y ago
      It was Google, not the users, which set the old pricing model which people optimized for when they wrote their apps. Many apps which had to be shut down were already doing "right" things like caching, using task queues, and economizing on datastore accesses. It was Google, not the users, which designed App Engine so that porting away would essentially require a rewrite. It was not the users but Google which neglected certain popular language runtimes so that they were no longer cost-effective after the price hikes. And it was Google, not the users, which kept the issue opaque so there was no warning of how big the price hikes were going to be. If certain users found that they could sustain a double or triple bill, that doesn't mean it is the fault of the other users that they were forced to mothball their apps. The users didn't decide any of these things, and are not to blame for them. What kind of service blames its customers for its own mistakes? Google earned this distrust fair and square by suddenly forcing huge numbers of customers to rewrite all their existing code. Little price cuts don't matter: other services are already more cost-effective and are cutting their prices all the time, but even if there were price parity the risk attached to the lock-in just isn't worth it.
  - jsmthrowaway 11y ago
    They published the pricing in May. Nobody cared until the calculator came out in September. You're selling it like Google gave everyone a week. The price increase also came with an SLA. Just to be clear, you're saying that businesses were entirely built atop a product with no SLA, and that's not the bigger problem?
CydeWeys 11y ago
That goes back to 2011. Has anything been changed on people more recently?
- deleted 11y ago
  [deleted]
- asah 11y ago
  yes: http://techcrunch.com/2014/03/25/google-drops-prices-for-compute-and-app-engine-by-over-30-cloud-storage-by-68-introduces-sustained-use-discounts/ http://techcrunch.com/2014/03/25/google-drops-prices-for-com... I run a $MM enterprise business almost entirely on GAE/python with a staff of ~40, public-facing site, etc and the monthly bill is under $1500/mon. Sure, I'd prefer lower $ and faster performance but truthfully, I'm no longer complaining: GAE/python saves me $$$ in IT staffing costs including security upgrades on dozens of packages that are either pre-integrated or I don't need at all (SQL & NoSQL databases incl multi-DC failover, memcache, reverse proxy, email hosting, auto-scaling, etc. etc.)
  - abritishguy 11y ago
    This doesn't surprise me at all. It is trivial to run a site on app engine that can handle hundreds of requests a second continuously without leaving the free tier. Sure, when the change from billing CPU time to instance hours came in some app's bills sky-rocketed. But that was because they were poorly coded such that instances were blocking and unable to serve incoming requests. With a thread safe application and the proper configuration there is absolutely no reason why instance-hours pricing shouldn't be competitive.
    - Nitramp 11y ago
      > This doesn't surprise me at all. It is trivial to run a site on app engine that can handle hundreds of requests a second continuously without leaving the free tier. Really? The free tier comes with 28 instance hours per day. That'd mean your app would have to serve hundreds of requests per second, meaning each request must take substantially less than 10 ms, on a 600 MHz, 128 MB RAM machine. If your request do any work at all, I doubt you can handle them in <10ms on a 600 MHz CPU.
csense 11y ago
I can immediately off the top off my head think of no less than four examples of useful services Google has discontinued or EOL'ed: Google Reader, Google Code, Google Wave, and XMPP support for Google Voice. So as well as potential future price hikes, you should be prepared for the possibility that this service might not be around for the long haul. Therefore you should skip using any Google-specific functionality, and instead implement a design that allows you to easily migrate to another VM vendor.
- Klathmon 11y ago
  I never got the "google shuts everything down" mentality that has become so prevalent. I could easily beat those 4 with a multitude of examples from both Apple and Microsoft, that doesn't mean that any of them are untrustworthy, just that they evolve and continue to grow. At least when google shuts down a service, they give a good amount of "heads up" to those using it, provide examples of trustworthy equivalent services from competitors, and ALWAYS provide an export function if it makes sense to have one.
  - superuser2 11y ago
    Apple and Microsoft may discontinue support/sales but the hardware/software they sold you continues to function. That is inherently not true of "cloud" services.
  - mst 11y ago
    > I never got the "google shuts everything down" mentality that has become so prevalent. Because their early marketing led people to not expect that of google, whereas with apple and microsoft it's just business as usual.
  - wwweston 11y ago
    > I could easily beat those 4 with a multitude of examples from both Apple and Microsoft that doesn't mean that any of them are untrustworthy No, that's pretty much what it means. To varying degrees when you build on top of Apple, Microsoft or Google offerings, you're sharecropping rather than farming. Sometimes, they'll just find that it's in their interest to no longer lease out the farm to you -- or to change the rates/terms. "Untrustworthy" might be an over strong term, if for no other reason than that invoking "trust" as a relevant concept in this context is probably itself incorrect.
abritishguy 11y ago
Before the pricing change app engine did not support concurrent requests to a single instance for python. As a result, applications used many more instances than they needed. When using the calculator this would make the price increase seem enormous to many customers. When concurrent request support was added (it was available to trusted testers at this time) all a user would have to do was add "threadsafe:true" to the app.yaml file to enable it (assuming their code wasn't doing anything silly).
jontro 11y ago
Deploying to app engine caused us big pain in the long run. I just had to spend two days migrating a legacy app to the new hrd. The migration was painful, app engine "billing bugs" when upgrading etc made the process real hard. Also when the bugs occured, I realised there was no way to get quick support. Thankfully we moved our main app away to ec2 around when they increased the pricing a couple of years ago.

by branola 11y ago

spankalee 11y ago

App Engine was in preview when its price changed.

branola 11y ago
It was in "preview" for 3 years. During those 3 years no warning was given that the pricing changes were going to be of such a magnitude. As a result people had sufficient time and not enough warning to build entire businesses on an infrastructure that they later had to abandon. That's unforgivable.
- Alupis 11y ago
  > build entire businesses on an infrastructure that they later had to abandon. Frankly, if your business is built entirely around a single 3rd party provider, and you are totally incapable of pivoting cloud providers at short notice... well then you are "doing it wrong".
  - discardorama 11y ago
    Like Netflix? They seem to be doing alright.
    - Alupis 11y ago
      > Like Netflix? They seem to be doing alright. Could you elaborate a little? Netflix doesn't rely on a single provider for hardware, data centers, nor bandwidth. Sure they use EC2 for some things, but also have a great deal of hardware in data centers throughout the country, as well as custom hardware in ISP data centers, etc. I'd be shocked if there didn't use some of the other cloud provider offering too. Netflix has no single point of failure. Building your business around a single cloud provider creates a single point of failure.
  - justonepost 11y ago
    That's the point that was made above. Don't build anything that relies on this architecture unless you can migrate.
- spankalee 11y ago
  The new pricing made it App Engine a sustainable business, because the old pricing model didn't actually account for costs and encouraged some very wasteful practices. The only other option to actually charging enough to cover costs would be to shut the service down. I'm sure more people would be more upset about that. App Engine has always been a unique PAAS because its APIs were designed to try to force developers into better distributed app architectures. The non-relational DB with entity groups and limited queries, the 30s request limit, originally not offering long-running instances, the task queue, memcache as a service, all made for scalable apps. But the costs unfortunately weren't designed the same way. Charging by CPU time, and having datastore access free was especially bad for a market where apps typically use very little CPU, but access data a lot. A lot of blog posts came shorty after the price change that said after making the recommended changes to datastore calls, and enabling multithreading that they got their bill down and performance up significantly. Many apps were doing absolutely no caching, or logging every request to the datastore, because datastore was ridiculously cheap for small records. Some were doing what should have been batch work per-request because they didn't use task queues. Since 2011, I think all price changes with Google Cloud have been price drops, some pretty big. Last year, App Engine prices were dropped 30%.
  - pekk 11y ago
    It was Google, not the users, which set the old pricing model which people optimized for when they wrote their apps. Many apps which had to be shut down were already doing "right" things like caching, using task queues, and economizing on datastore accesses. It was Google, not the users, which designed App Engine so that porting away would essentially require a rewrite. It was not the users but Google which neglected certain popular language runtimes so that they were no longer cost-effective after the price hikes. And it was Google, not the users, which kept the issue opaque so there was no warning of how big the price hikes were going to be. If certain users found that they could sustain a double or triple bill, that doesn't mean it is the fault of the other users that they were forced to mothball their apps. The users didn't decide any of these things, and are not to blame for them. What kind of service blames its customers for its own mistakes? Google earned this distrust fair and square by suddenly forcing huge numbers of customers to rewrite all their existing code. Little price cuts don't matter: other services are already more cost-effective and are cutting their prices all the time, but even if there were price parity the risk attached to the lock-in just isn't worth it.
- jsmthrowaway 11y ago
  They published the pricing in May. Nobody cared until the calculator came out in September. You're selling it like Google gave everyone a week. The price increase also came with an SLA. Just to be clear, you're saying that businesses were entirely built atop a product with no SLA, and that's not the bigger problem?

CydeWeys 11y ago

That goes back to 2011. Has anything been changed on people more recently?

deleted 11y ago
[deleted]
asah 11y ago
yes: http://techcrunch.com/2014/03/25/google-drops-prices-for-compute-and-app-engine-by-over-30-cloud-storage-by-68-introduces-sustained-use-discounts/ http://techcrunch.com/2014/03/25/google-drops-prices-for-com... I run a $MM enterprise business almost entirely on GAE/python with a staff of ~40, public-facing site, etc and the monthly bill is under $1500/mon. Sure, I'd prefer lower $ and faster performance but truthfully, I'm no longer complaining: GAE/python saves me $$$ in IT staffing costs including security upgrades on dozens of packages that are either pre-integrated or I don't need at all (SQL & NoSQL databases incl multi-DC failover, memcache, reverse proxy, email hosting, auto-scaling, etc. etc.)
- abritishguy 11y ago
  This doesn't surprise me at all. It is trivial to run a site on app engine that can handle hundreds of requests a second continuously without leaving the free tier. Sure, when the change from billing CPU time to instance hours came in some app's bills sky-rocketed. But that was because they were poorly coded such that instances were blocking and unable to serve incoming requests. With a thread safe application and the proper configuration there is absolutely no reason why instance-hours pricing shouldn't be competitive.
  - Nitramp 11y ago
    > This doesn't surprise me at all. It is trivial to run a site on app engine that can handle hundreds of requests a second continuously without leaving the free tier. Really? The free tier comes with 28 instance hours per day. That'd mean your app would have to serve hundreds of requests per second, meaning each request must take substantially less than 10 ms, on a 600 MHz, 128 MB RAM machine. If your request do any work at all, I doubt you can handle them in <10ms on a 600 MHz CPU.

csense 11y ago

I can immediately off the top off my head think of no less than four examples of useful services Google has discontinued or EOL'ed: Google Reader, Google Code, Google Wave, and XMPP support for Google Voice. So as well as potential future price hikes, you should be prepared for the possibility that this service might not be around for the long haul. Therefore you should skip using any Google-specific functionality, and instead implement a design that allows you to easily migrate to another VM vendor.

Klathmon 11y ago
I never got the "google shuts everything down" mentality that has become so prevalent. I could easily beat those 4 with a multitude of examples from both Apple and Microsoft, that doesn't mean that any of them are untrustworthy, just that they evolve and continue to grow. At least when google shuts down a service, they give a good amount of "heads up" to those using it, provide examples of trustworthy equivalent services from competitors, and ALWAYS provide an export function if it makes sense to have one.
- superuser2 11y ago
  Apple and Microsoft may discontinue support/sales but the hardware/software they sold you continues to function. That is inherently not true of "cloud" services.
- mst 11y ago
  > I never got the "google shuts everything down" mentality that has become so prevalent. Because their early marketing led people to not expect that of google, whereas with apple and microsoft it's just business as usual.
- wwweston 11y ago
  > I could easily beat those 4 with a multitude of examples from both Apple and Microsoft that doesn't mean that any of them are untrustworthy No, that's pretty much what it means. To varying degrees when you build on top of Apple, Microsoft or Google offerings, you're sharecropping rather than farming. Sometimes, they'll just find that it's in their interest to no longer lease out the farm to you -- or to change the rates/terms. "Untrustworthy" might be an over strong term, if for no other reason than that invoking "trust" as a relevant concept in this context is probably itself incorrect.

abritishguy 11y ago

Before the pricing change app engine did not support concurrent requests to a single instance for python. As a result, applications used many more instances than they needed. When using the calculator this would make the price increase seem enormous to many customers. When concurrent request support was added (it was available to trusted testers at this time) all a user would have to do was add "threadsafe:true" to the app.yaml file to enable it (assuming their code wasn't doing anything silly).

jontro 11y ago

Deploying to app engine caused us big pain in the long run. I just had to spend two days migrating a legacy app to the new hrd. The migration was painful, app engine "billing bugs" when upgrading etc made the process real hard. Also when the bugs occured, I realised there was no way to get quick support. Thankfully we moved our main app away to ec2 around when they increased the pricing a couple of years ago.