Live data from Hacker News

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

cloud.google.com

81–90 of 129 posts

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

#81
post #62
post #16

Earlier quoted context omitted.

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?

There are tools that enable this (e.g. look at temporal.io). As for external storage: yes, you do generate more metadata, but that's often a tiny fraction of the cost saved by moving to spot machines. In general, these tools are adopted more for increasing reliability of existing systems, but I predict they would be a neat fit to run them on spot machines.

+1 for Temporal. Using in prod, its great

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

#82
post #2

Any word on pricing?

Among other things, the price cuts are a nice change for ultra-cheap hobby projects that have extremely low resource demands. So far the lowest Spot VM price I've found is e2-micro in us-west4, which costs a whopping $0.69/month for 2GB of RAM and 0.25 of a shared core. That's only 25% the cost of Amazon's comparable t3a.small.

Keep in mind as far as I can tell there's a $1.44 fee for an external IP address (only if it's in use by a preemptible VM). If it's not in use, it's even higher.

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

#83

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

And that's a good thing. k8s configurations are rarely written. It's better to make them as clear as possible, even if it makes them verbose and long-to-type.

Same thing can be said about build scripts. Those who strive for terseness (hey sbt) become unreadable mess 1 year after writing, when you need to read them again.

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

#84
post #42
post #16

Earlier quoted context omitted.

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?

The reality at scale is that all cloud VMs are preemptible and unreliable. You can pay more to increase the probability of uptime but inevitably have to recover from failure sometimes.

The reality is itselt preemptible and unreliable, you could be terminated without notice

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

#85

It's weird how the 3 major clouds have taken different paths to what must be an almost identical resource allocation problem. AWS has had this kind of spot instance for years, but with a 2 minute grace period rather than the 30 seconds GCP is offering. Azure and GCP both originally went with the 24-hour cutoff (which can easily be replicated on a regular spot instance if needed), but now GCP are backing off on that r…

I don't remember Azure having the 24H cutoff. My spots/low priorities used to run for weeks

I used LP/spot both as scaling sets and the more recent single VMs

Also i wouldn't call the cutoff and grace period as "paths". There were much more substantial differences between the different clouds

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

#86
post #3

I don’t see this in the article, but is there any reason why they’d introduce a new VM type rather than just removing the 24hour limit of preemptible VMs?

Branding probably. Being inline with Azure and AWS is helpful when onboarding new customers

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

#87
post #3

I don’t see this in the article, but is there any reason why they’d introduce a new VM type rather than just removing the 24hour limit of preemptible VMs?

It's probably a niche use case, but there is some utility to having a guaranteed daily shutoff. For example, you might spin up an instance as an on-demand remote dev environment, and the 24 hour cutoff ensures it doesn't accidentally get left on (over a weekend, for example). This would be easy to work around, but nonetheless could lead to unexpectedly high charges if you were relying on this behavior only to have it…

It wasn't a 24H guarantee, it was UP TO 24h

It did guard you from keeping things on by mistake but there are way more downsides to this kind of restrictions. Especially that you can simulate the daily shutoff like other comments here said

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

#88
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)?

1. You only pay for compute time you actaully get 2. Any stateless process such as web servers are ideal for spots 3. Also k8s nodes are very good to run in spot since pods are "natively" crash "resistant"

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

#89
post #50

Is this a sign they have surplus pre-emptible capacity on their architecture for non-premptible VMs, and so worrying, if you think they have enough customers to sustain the model? (google could run negative forever: the point is, some VP won't want to, and the KPI will morph to "kill it")

Don't worry. Preemtible VMs were used by enough people and this pricing model is 100% profit for the clouds

This is just aligning the offering with Azure and AWS

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

#90
post #19
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)?

All our pernos.co infrastructure uses AWS spot VMs. Batch processing runs on spot and fails over to regular VMs as necessary. CI jobs run on spot. Our front-end server running the Web site and our application also runs on spot and automatically fails over to a regular VM if it gets terminated. Termination is rare.

How do you coordinate the failover? Custom scripts or?
Post reply on HN