Live data from Hacker News

Introducing Preemptible VMs

googlecloudplatform.blogspot.com

71–80 of 98 posts

Re: Introducing Preemptible VMs

#71
post #54
post #47

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".

That's the point that was made above. Don't build anything that relies on this architecture unless you can migrate.

Re: Introducing Preemptible VMs

#72
post #60
post #21

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://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…

That thing that jumps out at me from that example data set is that they were all free services. That's not to say there aren't fee-based services that Google has discontinued, or that your point isn't valid, just that your provided data points don't seem entirely relevant to me, given the subject.

Re: Introducing Preemptible VMs

#73
post #68

Earlier 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…

I don't think they are blaming the customers, and if you read posts from back then, I think they take a similar tone: they didn't get the pricing model right, and in order to make App Engine a real sustainable product with an SLA, they needed to update the pricing.

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

#74
post #15

Any 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.

EC2 spot instances give 2 minutes notice...

Re: Introducing Preemptible VMs

#75
As we put in the docs, to try this out:

  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

#76
post #22

I 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…

Google's cloud pricing is really terrible. Other competitors are intentionally driving prices down to dominate the market, so Google's prices kind of come across as a joke.

Re: Introducing Preemptible VMs

#77
post #22

I 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…

If I want to run a processing job that takes a 1000 core-hours and have the results today, I can do that on their VMs for a couple dollars per run. Being able to do that on owned hardware or dedicated hosts would be orders of magnitude more expensive.

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

#78

Nice! 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…

Could you point me at the datacenter utilization article? I can't seem to find it, and it sounds interesting

Re: Introducing Preemptible VMs

#79
post #58

Earlier 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…

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.

Re: Introducing Preemptible VMs

#80
post #21

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://g…

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).

Post reply on HN