Live data from Hacker News

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

cloud.google.com

91–100 of 129 posts

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

#91

Earlier quoted context omitted.

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.

It isn't written anywhere in the documentation, but the first 744 IP address-hours per month are charged at $0.00.

Link to pricing page: https://cloud.google.com/skus/?currency=USD&filter=C054-7F72...

That means if you just need one VM, you won't pay for IP charges.

Obviously that might change anytime without notice.

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

#92

Earlier quoted context omitted.

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.

It isn't written anywhere in the documentation, but the first 744 IP address-hours per month are charged at $0.00. Link to pricing page: https://cloud.google.com/skus/?currency=USD&filter=C054-7F72... That means if you just need one VM, you won't pay for IP charges. Obviously that might change anytime without notice.

Nice, thanks!

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

#93
post #13
post #12

Earlier quoted context omitted.

If your code can survive chaos monkey, it can trivially weather this. Netflix, as one example, could run their entire infrastructure on these VMs.

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.

Spot is excess capacity. If there's zero excess capacity, that means there's (probably) also no on-demand capacity as well.

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

#94
post #29
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?

I run a small CI system which starts relatively beefy preemptible instances for jobs. Normally those instances are terminated by the job scheduler as soon as there's nothing more to do. But it's a great peace of mind knowing they can't run for more than 24h if my job scheduler screws something up for whatever reason. I see it as a feature rather an a limitation for my use case.

Yes, but they could just provide a flag `maxLifetime` which defaults to `24h` but can be set to 0. (It can even only accept those two values)

Instead they created a whole new API for basically the same feature.

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

#95
post #29

Earlier quoted context omitted.

I run a small CI system which starts relatively beefy preemptible instances for jobs. Normally those instances are terminated by the job scheduler as soon as there's nothing more to do. But it's a great peace of mind knowing they can't run for more than 24h if my job scheduler screws something up for whatever reason. I see it as a feature rather an a limitation for my use case.

Yes, but they could just provide a flag `maxLifetime` which defaults to `24h` but can be set to 0. (It can even only accept those two values) Instead they created a whole new API for basically the same feature.

Creating a new api has greater "impact".

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

#96
post #22

Earlier quoted context omitted.

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…

In AWS we just `sudo shutdown +1440`. Then we can cancel the shutdown later if we need to.

There's some bug we keep hitting that causes some EC2 instances to reboot on shutdown instead of halt and terminate. AWS engineers promised a fix months ago, no news yet.

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

#97

So, probably a very naive question here, but how his the "continuity" across pre-emptions working? Say I am running a long batch process on one of these spot VMs and I get pre-empted ... Does my job restart where it was stopped automatically and everything is transparent save how long the job takes to complete, or do I have do to checkpointing myself and deal with the fact that my jobs may be killed at anytime? Also,…

Spot instances are the equivalent of stopping an instance while it's running. You get a signal (30 seconds prior for Google, 2 mins for AWS) and you are free to try and handoff the work to a different machine in your cluster .

Basically this is good for running short jobs and not long running ones. If you have a service that process chunks of data from a queue it's probably the ideal scenario.

In practice, with AWS your instances don't get killed that often. Some in the comments are claiming months but I was using mine with AWS Batch and they usually lived 1-2 weeks.

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

#98

So, probably a very naive question here, but how his the "continuity" across pre-emptions working? Say I am running a long batch process on one of these spot VMs and I get pre-empted ... Does my job restart where it was stopped automatically and everything is transparent save how long the job takes to complete, or do I have do to checkpointing myself and deal with the fact that my jobs may be killed at anytime? Also,…

Restarting the job is on you, the instance will be destroyed. So you'll need to adapt your process to be resumable (or partially resumable through checkpoints) and/or idempotent, so nothing goes wrong if you run the job (or parts of the job) twice.

OK, thanks, that answers my question: there is not continuity whatsoever, you have to take care of everything yourself.

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

#99
post #61

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…

They probably thought 24 hours limitation can store some design wins; their customers may have proved them wrong.

There are different win for both the approach. I train models on spot VMs which could take more than 24 hours. I set the price to be higher than reserved and there is very slim chance that training could be stopped and I get 80% saving on average. I don't want to spend time writing the complex logic to resume training after spot instance dies.

For services though, GCP pre-emptible instances are perfect combo for kubernetes.

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

#100

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

I seem to remember the Azure 24 hour limit being in place in 2018, though it wasn't highlighted particularly well and came as a surprise to me. Could well have been removed since.
Post reply on HN