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

31–40 of 245 posts

Re: AWS vs. GCP reliability is wildly different

#31

Post by nonameiguess »

shrubble wrote: post #12
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'…

Assuming this blurb is accurate: " General-purpose SSD volume (gp3) provides the consistent 125 MiB/s throughput and 3000 IOPS within the price of provisioned storage. Additional IOPS (up to 16,000) and throughput (1000 MiB/s) can be provisioned with an additional price. The General-purpose SSD volume (gp2) provides 3 IOPS per GiB storage provisioned with a minimum of 100 IOPS" ... then it seems like a device that li…

This would have been my guess. All EBS volumes are stored on a physical disk that supports the highest bandwidth and IOPS you can live migrate to, and the actual rates you get are determined by something in the interconnect. Live migration is thus a matter of swapping out the interconnect between the VM and the disk or even just relaxing a logical rate-limiter, without having to migrate your data to a different disk.

Re: AWS vs. GCP reliability is wildly different

#33

Post by epberry »

kccqzy wrote: post #23

Heard from a Googler that the internal infrastructure (Borg) is simply not optimized for quick startup. Launching a new Borg job often takes multiple minutes before the job runs. Not surprising at all.

Echoing this. The SRE book is also highly revealing about how Google request prioritization works. https://sre.google/sre-book/load-balancing-datacenter/

My personal opinion is that Google's resources are more tightly optimized than AWS and they may try to find the 99% best allocation versus the 95% best allocation on AWS.. and this leads to more rejected requests. Open to being wrong on this.

Re: AWS vs. GCP reliability is wildly different

#34

Post by danielmarkbruce »

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

If not a 4xx, what should they return for instance not available?

Re: AWS vs. GCP reliability is wildly different

#35

Post by sheeshkebab »

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

Maybe 1 reported. Not saying aws reliability is bad, but the number of various glitches that crop up in various aws services and not reflected on their status page is quite high.

Re: AWS vs. GCP reliability is wildly different

#36

Post by valleyjo »

kccqzy wrote: post #23

Heard from a Googler that the internal infrastructure (Borg) is simply not optimized for quick startup. Launching a new Borg job often takes multiple minutes before the job runs. Not surprising at all.

As another comment points out, GPU resources are less common so it takes longer to create, which makes sense. In general, start up times are pretty quick on GCP as other comments also confirm.

Re: AWS vs. GCP reliability is wildly different

#37

Post by chrismarlow9 »

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 mean if you're talking about worst case systems you assume everything is gone except your infra code and backups. In that case your instance launch time would ultimately define what your downtime looks like assuming all else is equal. It does seem a little weird to define it that way but in a strict sense maybe not.

Re: AWS vs. GCP reliability is wildly different

#38

Post by staringback »

duskwuff wrote: post #17

... why does the first graph show some instances as having a negative launch time? Is that meant to indicate errors, or has GCP started preemptively launching instances to anticipate requests?

Perhaps if you read the line directly about the graph you would see it was explained and would not have to ask this question

Re: AWS vs. GCP reliability is wildly different

#39

Post by santoshalper »

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 won't go so far as saying "you didn't read the article", but I think you missed something.

Re: AWS vs. GCP reliability is wildly different

#40

Post by theamk »

sheeshkebab wrote: post #35
xmonkee wrote: post #16

Earlier quoted context omitted.

GCP also had 84 errors compared to 1 for AWS

Maybe 1 reported. Not saying aws reliability is bad, but the number of various glitches that crop up in various aws services and not reflected on their status page is quite high.

that was measured from API call return codes, not by looking at overall service status page

Amazon is pretty good about this, if their API says machine is ready, it usually is.

Post reply on HN