3 ms·

B2 didn't used to be multiple ADs, or at least not multiple ADs over a wider geographic area, like AWS's regions. I'm not sure if that's changed at all. It us

B2 didn't used to be multiple ADs, or at least not multiple ADs over a wider geographic area, like AWS's regions. I'm not sure if that's changed at all. It used to be why B2 was able to be cheaper. You were paying for less durability and availability. S3 storage is redundant over an entire region. Entire availability zones can go down (extremely improbable) without your data being put at risk. It, therefore, struck me as odd to see: > Due to S3 and B2 being at least nearly equally* accessible, reliable, available, as well as many other providers, our primary reason for moving our backups now became pricing. but then ... > * Science is hard, blue keys on calculators are tricky, and we don’t have years to study things before doing them WTF? They're trying to be joking here I hope, but that comes across somewhat "We don't give a crap about our customer's data".

gregorysudderth 8y ago
Sorry for the bad vibe. I was trying to interject some humor into a dry process. When I asked a couple peers from my storage background, "how would you do this project" they both said the same thing: 1) form a working group 2) do a study 3) test 4) 90 days later, do an analysis. Epic process. We care a lot, but that's beyond our scope. This was an all-hands reviewed process, and like machines that are built to be ultimately reliable including: hospital generators, human-rated spacecraft equipment, airplane engines for single-engine remote location flying (PT6), our process was detuned speed-wise specifically, for overall service reliability and minimal impact. We tested, we analyzed, we saw weird failures (python core dump?) in simple code, and followed up on all of those before proceeding. We agonized. In the end we were satisfied, because our customers couldn't tell anything changed, and our CSR's got zero new tickets. Not bragging at all, relieved of course, but, we care about the CSR's load and work experience too. Thanks for checking the article out, and let me know if we can show you more about our service.

gregorysudderth 8y ago

Sorry for the bad vibe. I was trying to interject some humor into a dry process. When I asked a couple peers from my storage background, "how would you do this project" they both said the same thing: 1) form a working group 2) do a study 3) test 4) 90 days later, do an analysis. Epic process. We care a lot, but that's beyond our scope. This was an all-hands reviewed process, and like machines that are built to be ultimately reliable including: hospital generators, human-rated spacecraft equipment, airplane engines for single-engine remote location flying (PT6), our process was detuned speed-wise specifically, for overall service reliability and minimal impact. We tested, we analyzed, we saw weird failures (python core dump?) in simple code, and followed up on all of those before proceeding. We agonized. In the end we were satisfied, because our customers couldn't tell anything changed, and our CSR's got zero new tickets. Not bragging at all, relieved of course, but, we care about the CSR's load and work experience too. Thanks for checking the article out, and let me know if we can show you more about our service.