Live data from Hacker News

GCP releases Spot VMs, the next generation of Pre-emptible VMs

cloud.google.com

31–40 of 129 posts

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#31
post #7

I have trouble thinking of a use case that fits this VM type. Is it for batch processing tasks that don't have tight deadlines? The lack of any real guarantees makes it hard to price, as you have no idea what you're actually paying for. Would it make sense to have a model that includes deadlines in its pricing (like give this process 2.5 hours of CPU and 4GB of RAM to complete this task by...next Tuesday)?

> Is it for batch processing tasks that don't have tight deadlines?

I used to work for a company (since shut down) which provided big data processing systems in the cloud. This was one of the typical use-cases for our customers. Big data systems like Hadoop, Spark, etc are built to handle this kind of disruption where you lose a few nodes once in a while, and we had built in further optimizations to do it even better. This fact, combined with the much cheaper price of Spot Instances (upto 90% less than on-demand) make them a compelling alternative to on-demand instances.

In practice - at least on AWS - spot loss used to be quite rare. When it happened, it happened by the truckload, but we used to have spot instances run for several days without termination.

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#32

“requiredDuringSchedulingIgnoredDuringExecution” .. wow, what an epic length for a configuration option!

I guess you haven't worked with Hadoop. Here's an example of what configuration option names in it can look like:

    dfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#33
post #32

“requiredDuringSchedulingIgnoredDuringExecution” .. wow, what an epic length for a configuration option!

I guess you haven't worked with Hadoop. Here's an example of what configuration option names in it can look like: dfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction

Is length really a problem? I definitely prefer this over, eg.

     dfs.datanode.asvcp.bspf

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#34

It appears that GCP is rather late to the party here. I believe AWS has had spot instances for a very long time (more than 5 years at least) Is my understanding correct? and if so any insights on why it took so long

GCP has had Preemptible VMs, which WILL terminate after 24 hours if it lasted that long. Spot VMs removes this 24h limit.

They also changed the pricing model. Preempts had a completely predictable discount, and spot VM's have a variable discount.

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#35
post #31
post #7

I have trouble thinking of a use case that fits this VM type. Is it for batch processing tasks that don't have tight deadlines? The lack of any real guarantees makes it hard to price, as you have no idea what you're actually paying for. Would it make sense to have a model that includes deadlines in its pricing (like give this process 2.5 hours of CPU and 4GB of RAM to complete this task by...next Tuesday)?

> Is it for batch processing tasks that don't have tight deadlines? I used to work for a company (since shut down) which provided big data processing systems in the cloud. This was one of the typical use-cases for our customers. Big data systems like Hadoop, Spark, etc are built to handle this kind of disruption where you lose a few nodes once in a while, and we had built in further optimizations to do it even better…

I've had AWS spot instances run for months without termination.

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#37
post #20
post #13

Earlier quoted context omitted.

Except that (presumably) there is no guarantee that any spot instances are available. You could wind up in a state where you have no instances running. No user-facing production service can tolerate that.

Just spin up regular VMs if you can't get spot instances when you need them.

Lack of spot VM means that all spare capacity has been taken up by the regular VMs, meaning that it spots are gone, so are regular ones.

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#38
post #16
post #10

Earlier quoted context omitted.

You might be misunderstanding how spot works. The VM either runs at full speed or not at all so you know what you're getting.

Nevertheless, doesn't that force you to divide your work up into units somehow and manage external storage to track what/how much is done?

You gotta do that anyway. It really sucks when a multi-day job crashes halfway through because of some silly bug and then you gotta restart from the beginning. The ability to resume from crashes is required regardless of where you're running the code.

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#39
post #7

I have trouble thinking of a use case that fits this VM type. Is it for batch processing tasks that don't have tight deadlines? The lack of any real guarantees makes it hard to price, as you have no idea what you're actually paying for. Would it make sense to have a model that includes deadlines in its pricing (like give this process 2.5 hours of CPU and 4GB of RAM to complete this task by...next Tuesday)?

They are also great if you are paying out of your own pocket and not your employer's. For side projects, academic work, etc., that need GPU instances or large memory instances, the regular pricing is quite out of whack. Spot pricing makes it tolerable.

Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs

#40
post #26
post #25

Earlier quoted context omitted.

Tha sounds like a horrific dev environment, if randomly shut down with 30 seconds notice.

I can imagine it being useful if you needed to test something out for an hour or two and were worried you might forget to shut it down. Your charges are capped at 24h no matter how badly you screw up.

If a test workload goes wrong in an interesting way, someone would very likely want to ssh there to poke around. If the poking extends to ~24 hours later, it is bound to get brutally interrupted. The worst part, there is no easy way to avoid it. (Well, one could shut it down and start again to reset the 24-hour timer, but that is cumbersome comparing to removing a `shutdown` line from crontab of a spot instance.)
Post reply on HN