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.
GCP releases Spot VMs, the next generation of Pre-emptible VMs
81–90 of 129 posts
Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs
#82Any 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.
Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs
#83“requiredDuringSchedulingIgnoredDuringExecution” .. wow, what an epic length for a configuration option!
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
#84Earlier 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.
Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs
#85It'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 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
#86I 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?
Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs
#87I 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 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
#88I 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)?
Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs
#89Is 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")
This is just aligning the offering with Azure and AWS
Re: GCP releases Spot VMs, the next generation of Pre-emptible VMs
#90I 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.