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

141–150 of 245 posts

Re: AWS vs. GCP reliability is wildly different

#141

Post by somat »

rco8786 wrote: post #108
somat wrote: post #86

Earlier quoted context omitted.

It is not reliably running the machine but reliably getting the machine. Like the article said, The promise of the cloud is that you can easily get machines when you need them the cloud that sometimes does not get you that machine(or does not get you that machine in time) is a less reliable cloud than the one that does.

It’s still performance. If this was “AWE failed to deliver the new machines and GCP delivered”, sure, reliability. But this isn’t that. The race car that finishes first is not “more reliable” than the one in 10th. They are equally as reliable, having both finished the race. The first place car is simply faster at the task.

The one in first can more reliably win races however.

Re: AWS vs. GCP reliability is wildly different

#143

Post by thesuperbigfrog »

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?

"AWS encountered one valid launch error in these two weeks whereas GCP had 84."

84 times more launch errors seems like a valid definition for "less reliable".

Re: AWS vs. GCP reliability is wildly different

#144

Post by zylent »

Animats wrote: post #135

> 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. That would seem to indicate that asking for a VM on GCP gets you a minimally configured VM on basic hardware, and then it gets migrated to something bigger if you ask for more resources. Is that correct? That could make sense if, much of the time, users get a VM and spend a lot…

This is not quite true - GPU's are limited to select VM types, and the number of GPU's you have influences the maximum number of cores you can get. In general they're only available on the n1 instances (except the a100's, but those are far less popular)

Re: AWS vs. GCP reliability is wildly different

#145

Post by okdood64 »

rwiggins wrote: post #127

There were 84 errors for GCP, but the breakdown says 74 409s and 5 timeouts. Maybe it was 79 409s? Or 10 timeouts? I suspect the 409 conflicts are probably from the instance name not being unique in the test. It looks like the instance name used was: instance_name = f"gpu-test-{int(time())}" which has a 1-second precision. The test harness appears to do a `sleep(1)` between test creations, but this sort of thing can…

Hope icyfox can try running this with a fix.

Re: AWS vs. GCP reliability is wildly different

#146

Post by irjustin »

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?

I'll say it is valid to use reliability.

If I depend on some performance metric, startup, speed, etc, my dependance on it equates to reliability. Not just on/off but the spectrum that it produces.

If a CPU doesn't operate at its 2GHz setting 60% of the time, I would say that's not reliable. When my bus shows up on time only 40% of the time - I can't rely on that bus to get me where I need to go consistently.

If the GPU took 1 hour to boot, but still booted, is it reliable? What about 1 year? At some point it tips over an "personal" metric of reliability.

The comparison to AWS which consistently out-performs GCP, while not explicitly, implicitly turns that into a reliability metric by setting the AWS boot time as "the standard".

Re: AWS vs. GCP reliability is wildly different

#147

Post by RajT88 »

lacker wrote: post #116

Anecdotally I tend to agree with the author. But this really isn't a great way of comparing cloud services. The fundamental problem with cloud reliability is that it depends on a lot of stuff that's out of your control, that you have no visibility into. I have had services running happily on AWS with no errors, and the next month without changing anything they fail all the time. Why? Well, we look into it and it turn…

Instance types and regions make a big difference.

Some regions and hardware generations are just busier than others. It may not be the same across cloud providers (although I suspect it is similar given the underlying market forces).

Re: AWS vs. GCP reliability is wildly different

#148

Post by RajT88 »

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?

Reliability is a fair term, with an asterix. It is a specific flavor of reliability: deployment or scaling or net-new or allocation or whatever you want to call it.

Re: AWS vs. GCP reliability is wildly different

#149

Post by mnutt »

It may or may not matter for various use cases, but the EC2 instances in the test use EBS and the AMIs are lazily loaded from S3 on boot. So it may be possible that the boot process touches few files and quickly gets to 'ready' state, but you may have crummy performance for a while in some cases.

I haven't used GCP much, but maybe they load the image onto the node prior to launch, accounting for some of the launch time difference?

Re: AWS vs. GCP reliability is wildly different

#150

Post by antonvs »

xmonkee wrote: post #16
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?

GCP also had 84 errors compared to 1 for AWS

Another comment on this thread pointed out they had a potential collision in their instance name generation which may have caused this. That would mean this was user error, not a reliability issue. AWS doesn’t require instance names to be unique.
Post reply on HN