Earlier quoted context omitted.
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.
> 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".
Introducing Preemptible VMs
71–80 of 98 posts
Re: Introducing Preemptible VMs
#72Any 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://g…
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, a…
Re: Introducing Preemptible VMs
#73Earlier quoted context omitted.
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…
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…
https://plus.google.com/110401818717224273095/posts/AA3sBWG9...
As for the unique API, of course some of it's unique, because there weren't any standard APIs for the unique parts. Datastore is based on Google's internal NoSQL store. There's are/were standard APIs for NoSQL. Same with Task Queues.
The "proprietary API" bit is overblown though, IMO. The Python version shipped with a somewhat tweaked, Django support, and has grown to support WSGI and standard Django. The Java version uses Servlets with some constraints. Memcache is pretty standard. You can pretty easily abstract away the proprietary bits to run on a standard stack, or use an open source implementation of the APIs.
Re: Introducing Preemptible VMs
#74Any reason you couldn't use these for conventional web stuff? 30 seconds could easily be long enough to bring up another instance and sync data if needed.
I would say it depends on the size of your pool. 30 seconds _is not_ long enough to bring up another instance.
Re: Introducing Preemptible VMs
#75 gcloud compute instances create my-vm --preemptible --zone=us-central1-c
or just set the preemptible bool to true via the API (it's under scheduling). When you want to test how your system behaves on preemption, you can just do: gcloud compute instances stop my-vm --zone=us-central1-c
which will give you the same 30 second timeout as when you're preempted. Most OSes have a fairly standard set of things they do on shutdown that will at least send all your running processes a signal (via kill), but if you need to add your own you can inject it via the new shutdown script support (https://cloud.google.com/compute/docs/shutdownscript).We tried to cover this in the docs (https://cloud.google.com/compute/docs/instances/preemptible) any feedback on that would be welcome!
Re: Introducing Preemptible VMs
#76I might be missing something important here. But according to their pricing page[1], a preemtible VM with 30GB memory costs $86.4 a month. Why would someone go for this when cheap dedicated host providers like hetzner etc offer powerful dedicated servers with 64GB memory and multicore server grade CPUs? The comparison only gets worse taking into account that Google's offering is preemptible and can shutdown and come…
Re: Introducing Preemptible VMs
#77I might be missing something important here. But according to their pricing page[1], a preemtible VM with 30GB memory costs $86.4 a month. Why would someone go for this when cheap dedicated host providers like hetzner etc offer powerful dedicated servers with 64GB memory and multicore server grade CPUs? The comparison only gets worse taking into account that Google's offering is preemptible and can shutdown and come…
Similarly, if you're running hosted app that on most hours doesn't overload a single server, on peak hour fills three hosts, but on a large advertising event or accidental viral link takes fifty hosts for a day, and then goes back to normal - then you don't want to run it on VMs where you have to pay for them by month.
Re: Introducing Preemptible VMs
#78Nice! This ties in with the discussion yesterday on HN about data center utilization. Good for saving money and the end result must be lower global energy use if this also catches on with other providers (AWS already offers something similar). When I worked at Google in 2013 part of my job was running very large calculations that were often pre-empted. I usually ran at the lowest priority and was in effect using spar…
Re: Introducing Preemptible VMs
#79Earlier quoted context omitted.
That goes back to 2011. Has anything been changed on people more recently?
yes: 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 p…
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.
Re: Introducing Preemptible VMs
#80Any 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://g…
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).