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

AWS vs. GCP reliability is wildly different

freeman.vc

Post reply on HN
Print view View original

71–80 of 245 posts

Re: AWS vs. GCP reliability is wildly different

#71

Post by rco8786 »

mikewave wrote: post #46
dark-star wrote: post #13

I wonder why someone would equate "instance launch time" with "reliability"... I won't go as far as calling it "clickbait" but wouldn't some other noun ("startup performance is wildly different") have made more sense?

Well, if your system elastically uses GPU compute and needs to be able to spin up, run compute on a GPU, and spin down in a predictable amount of time to provide reasonable UX, launch time would definitely be a factor in terms of customer-perceived reliability.

Sure but not anywhere remotely near clearing the bar to simply calling that “reliability”.

Re: AWS vs. GCP reliability is wildly different

#72

Post by dilyevsky »

dekhn wrote: post #45

What would you expect? AWS is an org dedicated to giving customers what they want and charging them for it, while GCP is an org dedicated to telling customers what they want and using the revenue to get slightly better cost margins on Intel servers.

I don’t believe this reasoning is used since at least Diane

Re: AWS vs. GCP reliability is wildly different

#73

Post by lbhdc »

prmoustache wrote: post #56
pclmulqdq wrote: post #30

Earlier quoted context omitted.

They pause your VM, copy everything about its state over to the new machine, and quickly start the other instance. It's pretty clever. I think there are tricks you can play with machines that have large memory footprints to copy most of it before the pause, and only copy what has changed since then during the pause. The disks are all on the network, so no need to move anything there.

In reality it sync the memory first to the other host and only pause the vm when the last state sync is small enough to be so quick the pause is barely measurable.

When its transferring the state to the target, how does it handle memory updates that are happening at that time? Is the programs execution paused at that point?

Re: AWS vs. GCP reliability is wildly different

#76

Post by master_crab »

btgeekboy wrote: post #43
remus wrote: post #19

> The offerings between the two cloud vendors are also not the same, which might relate to their differing response times. GCP allows you to attach a GPU to an arbitrary VM as a hardware accelerator - you can separately configure quantity of the CPUs as needed. AWS only provisions defined VMs that have GPUs attached - the g4dn.x series of hardware here. Each of these instances are fixed in their CPU allocation, so if…

I wouldn't be surprised if GCP has GPUs scattered throughout the datacenter. If you happen to want to attach one, it has to find one for you to use - potentially live migrating your instance or someone else's so that it can connect them. It'd explain the massive variability between launch times.

Yeah that was my thought too when I first read the blurb.

It’s neat…but like a lot of things in large scale operations, the devil is in the details. GPU-CPU communications is a low latency high bandwidth operation. Not something you can trivially do over standard TCP. GCP offering something like that without the ability to flawlessly migrate the VM or procure enough “local” GPUs means it’s just vaporware.

As a side note, I’m surprised the author didn’t note the amount of ICE’s (insufficient capacity errors) AWS throws whenever you spin up a G type instance. AWS is notorious for offering very few G’s and P’s is certain AZs and regions.

Re: AWS vs. GCP reliability is wildly different

#77

Post by dekhn »

dilyevsky wrote: post #72
dekhn wrote: post #45

What would you expect? AWS is an org dedicated to giving customers what they want and charging them for it, while GCP is an org dedicated to telling customers what they want and using the revenue to get slightly better cost margins on Intel servers.

I don’t believe this reasoning is used since at least Diane

I haven't seen any real change from Google about how they approach cloud in the past decade (first as an employee and developer of cloud services there, and now as a customer). Their sales people have hollow eyes

Re: AWS vs. GCP reliability is wildly different

#78

Post by VWWHFSfQ »

rco8786 wrote: post #71
mikewave wrote: post #46

Earlier quoted context omitted.

Well, if your system elastically uses GPU compute and needs to be able to spin up, run compute on a GPU, and spin down in a predictable amount of time to provide reasonable UX, launch time would definitely be a factor in terms of customer-perceived reliability.

Sure but not anywhere remotely near clearing the bar to simply calling that “reliability”.

I would still call it "reliability".

If the instance takes too long to launch then it doesn't matter if it's "reliable" once it's running. It took too long to even get started.

Re: AWS vs. GCP reliability is wildly different

#79

Post by Salgat »

politelemon wrote: post #3

A few weeks ago I needed to change the volume type on an EC2 instance to gp3. Following the instructions, the change happened while the instance was running. I didn't need to reboot or stop the instance, it just changed the type. While the instance was running. I didn't understand how they were able to do this, I had thought volume types mapped to hardware clusters of some kind. And since I didn't understand, I wasn'…

If I remember right they use the equivalent of a ledger of changes to manage volume state. So in this case, they copy over the contents (up to a certain point in time) to the new faster virtual volume, then append and direct all new changes to the new volume.

This is also how they are able to snapshot a volume at a certain point in time without having any downtime or data inconsistencies.

Re: AWS vs. GCP reliability is wildly different

#80

Post by endisneigh »

VWWHFSfQ wrote: post #78
rco8786 wrote: post #71

Earlier quoted context omitted.

Sure but not anywhere remotely near clearing the bar to simply calling that “reliability”.

I would still call it "reliability". If the instance takes too long to launch then it doesn't matter if it's "reliable" once it's running. It took too long to even get started.

that's not what reliability means
Post reply on HN