Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Preemptible VMs

googlecloudplatform.blogspot.com

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Introducing Preemptible VMs

#91

Post by nl »

tw04 wrote: post #88
nightcracker wrote: post #44

Earlier quoted context omitted.

> Though to build a business model around a resource you can't even determine the availability of. That's exactly why it's cheap: you're trading price for reliability.

reliability != availability. I can build a business model around an unreliable, but available resource. I can't build a business model around an unavailable resource. They're two very different things, and the distinction is important.

This basically for batch-processing. That means that the lack of availability isn't such an issue because this lets you trade speed-of-processing for cost.

Say you have a few hundred terabytes of images to process. You can prioritize images by pushing them to the head of the queue, but you don't really care how long the complete batch takes.

If you are happy to wait for your job to complete you pay less. Otherwise, pay more and guarantee completion.

Re: Introducing Preemptible VMs

#92

Post by jpatokal »

bitJericho wrote: post #89

At a penny per core per instance hour the cost is about 7 dollars a month. I can get a normal dedicated VM for cheaper... What's the benefit in this?

> What's the benefit in this?

You're not buying a dedicated instance for a month, you're renting it as long as you need it. If you only need a core for an hour, your bill will be $0.01.

Re: Introducing Preemptible VMs

#93

Post by jpatokal »

teraflop wrote: post #66
vosper wrote: post #18

Earlier quoted context omitted.

The fundamental difference seems to be that Google's prices are fixed, whereas AWS uses a "market" model, which frequently sees crazy prices (well over the on-demand price) especially in us-east-1. I say "market" because no-one really knows how the spot market place actually works. We've had machines run for weeks, and other times the prices fluctuate in bizarre ways and we can't get out preferred instance types for…

I don't really see a fundamental difference except that Google's offering is more opaque and less flexible. Instead of "your instance got killed, but you can restart it if you're willing to pay $x/hour", you get "your instance got killed, tough luck." EC2's spot market fluctuates based on supply and demand, and there's no reason to think the same forces won't apply to GCE.

It's not really that different: If your preemptible GCE instance gets killed, you can try restarting it as a 'normal' (non-preemptible) instance. But in Google's case, both prices will be predictable.

Re: Introducing Preemptible VMs

#94

Post by mst »

Klathmon wrote: post #62
csense wrote: post #60

Earlier quoted context omitted.

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…

I never got the "google shuts everything down" mentality that has become so prevalent. I could easily beat those 4 with a multitude of examples from both Apple and Microsoft, that doesn't mean that any of them are untrustworthy, just that they evolve and continue to grow. At least when google shuts down a service, they give a good amount of "heads up" to those using it, provide examples of trustworthy equivalent serv…

> I never got the "google shuts everything down" mentality that has become so prevalent.

Because their early marketing led people to not expect that of google, whereas with apple and microsoft it's just business as usual.

Re: Introducing Preemptible VMs

#95

Post by wwweston »

Klathmon wrote: post #62
csense wrote: post #60

Earlier quoted context omitted.

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…

I never got the "google shuts everything down" mentality that has become so prevalent. I could easily beat those 4 with a multitude of examples from both Apple and Microsoft, that doesn't mean that any of them are untrustworthy, just that they evolve and continue to grow. At least when google shuts down a service, they give a good amount of "heads up" to those using it, provide examples of trustworthy equivalent serv…

> I could easily beat those 4 with a multitude of examples from both Apple and Microsoft that doesn't mean that any of them are untrustworthy

No, that's pretty much what it means. To varying degrees when you build on top of Apple, Microsoft or Google offerings, you're sharecropping rather than farming. Sometimes, they'll just find that it's in their interest to no longer lease out the farm to you -- or to change the rates/terms.

"Untrustworthy" might be an over strong term, if for no other reason than that invoking "trust" as a relevant concept in this context is probably itself incorrect.

Re: Introducing Preemptible VMs

#96

Post by Nitramp »

abritishguy wrote: post #84
Nitramp wrote: post #83

Earlier quoted context omitted.

> 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. Really? The free tier comes with 28 instance hours per day. That'd mean your app would have to serve hundreds of requests per second, meaning each request must take substantially less than 10 ms, on a 600 MHz, 128 MB RAM machine. If your request do any…

>meaning each request must take substantially less than 10 ms Correction, each request would need to have less than 10ms of CPU time - the instances support concurrency. My web frontend, by design, does very little - any CPU heavy operations are done by other systems using the task queue. Writing it in golang has helped as well, wouldn't get that performance from python. Write a simple Hello world example in golang a…

Yes, the 10 ms would be CPU time, not wall time.

But still, 10 ms really is not a lot on a 600 MHz machine. How long does your front end take to serve one request? How many qps do you serve from a single instance?

I have some go code with a trivial, completely unoptimized blog, rendering a couple of articles. Poking at appstats suggests I spend a bit more than 10 ms CPU time, App Engine reports ~30 ms CPU time.

Re: Introducing Preemptible VMs

#97

Post by abritishguy »

Nitramp wrote: post #96
abritishguy wrote: post #84

Earlier quoted context omitted.

>meaning each request must take substantially less than 10 ms Correction, each request would need to have less than 10ms of CPU time - the instances support concurrency. My web frontend, by design, does very little - any CPU heavy operations are done by other systems using the task queue. Writing it in golang has helped as well, wouldn't get that performance from python. Write a simple Hello world example in golang a…

Yes, the 10 ms would be CPU time, not wall time. But still, 10 ms really is not a lot on a 600 MHz machine. How long does your front end take to serve one request? How many qps do you serve from a single instance? I have some go code with a trivial, completely unoptimized blog, rendering a couple of articles. Poking at appstats suggests I spend a bit more than 10 ms CPU time, App Engine reports ~30 ms CPU time.

Typical request: "X-AppEngine-Resource-Usage ms=259 cpu_ms=4"

That particular request is authenticated, writes a file to google storage, and then returns a response (with a few other things like logging etc.)

Re: Introducing Preemptible VMs

#98

Post by breakingcups »

giulianob wrote: post #46
sologoub wrote: post #41

Earlier quoted context omitted.

You'd have to make sure that if a node gets terminated while processing a request, that request can be re-routed to a live VM. Unless you don't care about users randomly seeing errors of course.

They give you 30 seconds to shut down. Should be plenty of time to gracefully end your current requests and shut down the web server.

Is it enough time to spin up a new instance though, if needed?
Post reply on HN