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

Dropbox’s Exodus from the Amazon Cloud

wired.com

Post reply on HN
Print view View original

51–60 of 252 posts

Re: Dropbox’s Exodus from the Amazon Cloud

#51

Post by AngrySkillzz »

ignoramous wrote: post #24

Key points: 1. Dropbox moved from AWS to its own datacenters after 8 months of rigourous testing. They didn't exactly build a S3 clone, but something tailored to their needs, they named it Magic Pocket. 2. Dropbox still uses AWS for its European customers. 3. Dropbox hired a bunch of engineers from Facebook to build its own hardware heavily customised for data-storage and IOPS (naturally) viz. Diskotech. Some 8 Disko…

At the end of the blog post, they mention that they're working on creating the ability for European companies to store data in Germany if requested. This is interesting as the implication is that European businesses don't see the US as a safe place to store their data anymore.

Re: Dropbox’s Exodus from the Amazon Cloud

#52

Post by jamwt »

james_cowling wrote: post #49
riobard wrote: post #37

> Measuring only one-and-half-feet by three-and-half-feet by six inches, each Diskotech box holds as much as a petabyte of data This number is very interesting. Basically Diskotech stores 1PB in 18" × 6" × 42" = 4,536 cubic inch volume, which is 10% bigger than standard 7U (17" × 12.2" × 19.8" = 4,107 cubic inch). 124 days ago Dropbox Storage Engineer jamwt posted here ( https://news.ycombinator.com/item?id=10541052…

To be fair to Backblaze this level of storage density is really only possible with recent advances in disk technology (higher densities, SMR storage, etc). Also not everyone wants to be packing a petabyte into a box. At that level of density you need to invest a lot of effort in replication strategies, tooling, network fabric etc to handle failures with high levels of availability/durability.

Yes, a 1PB+ failure domain only made sense because Magic Pocket is very good at automatic cluster management and repair.

Re: Dropbox’s Exodus from the Amazon Cloud

#53

Post by jl6 »

jamwt wrote: post #39
riobard wrote: post #37

> Measuring only one-and-half-feet by three-and-half-feet by six inches, each Diskotech box holds as much as a petabyte of data This number is very interesting. Basically Diskotech stores 1PB in 18" × 6" × 42" = 4,536 cubic inch volume, which is 10% bigger than standard 7U (17" × 12.2" × 19.8" = 4,107 cubic inch). 124 days ago Dropbox Storage Engineer jamwt posted here ( https://news.ycombinator.com/item?id=10541052…

The difference to get even higher is our system supports host-managed SMR disks that come in 10T and 14T sizes.

I've never heard of a 14TB disk drive. Is that what you mean? Who makes these?

Re: Dropbox’s Exodus from the Amazon Cloud

#54

Post by myth_drannon »

Now that Golang is making headways at Dropbox, I guess Python codebase will diminish in its importance... I wonder how Guido Van Rossum feels about it. First he was at Google but they created Go and he left to Dropbox which was a large Python shop, now they are moving to Go too.

Re: Dropbox’s Exodus from the Amazon Cloud

#55

Post by james_cowling »

ignoramous wrote: post #26
jamwt wrote: post #2

Hi HN! A couple of us from the Magic Pocket software team are around to answer questions if anyone has some.

Please do a technical blog post on some of these: 1. Go vs Rust at Dropbox's scale and requirements. 2. Maintaining availability whilst moving from AWS to Diskotech and Magic Pocket. 3. Internals of Magic Pocket (file-system, storage engine, availability guarantees, scaling up and scaling out, compression details, load balancing, cloning etc) 4. Improvements in perf, stability, security, and cost. Thanks.

Yep we're going to get at least a few actual technical blog posts online in the coming month. We haven't got around to writing them yet tho so feel free to surface any requests :)

Will most likely start with the following: 1. Overall architecture and internals. 2. Verification and projection mechanisms, how we keep data safe. 3. How we manage a large amount of hardware (hundreds of thousands of disks) with a small team, how we automatically deal with alerts etc. 4. A deep-dive into the Diskotech architecture and how we changed our storage layer to support SMR disks.

Hopefully these will be of a sufficient level of detail. We certainly won't be getting into any details on cost but we're pretty open from a technical perspective.

(Lemme just take a moment to say how great Backblaze's tech blog posts are btw.)

Re: Dropbox’s Exodus from the Amazon Cloud

#56

Post by honeyman »

ignoramous wrote: post #24

Key points: 1. Dropbox moved from AWS to its own datacenters after 8 months of rigourous testing. They didn't exactly build a S3 clone, but something tailored to their needs, they named it Magic Pocket. 2. Dropbox still uses AWS for its European customers. 3. Dropbox hired a bunch of engineers from Facebook to build its own hardware heavily customised for data-storage and IOPS (naturally) viz. Diskotech. Some 8 Disko…

Thanks a lot for summarizing it for those who could not read the article due to the Wired adblock-preventing nag screen!

Re: Dropbox’s Exodus from the Amazon Cloud

#57

Post by moomin »

SeanDav wrote: post #47
james_cowling wrote: post #44

Earlier quoted context omitted.

Yup, Dropbox Infra is mostly a Go shop. It's our primary development language and we don't plan to switch off any time soon. We're always about the right tool for the job tho, and there are definitely use cases where Rust makes a lot of sense. We've been really happy with it so far.

Without getting into any sort of religious war, what are typical use cases that make Rust a better choice?

The really big deal is memory management. There's no GC, and there's pretty precise memory control, and it's not the Shub-Niggurath that dealing with C++ is.

In fact, just think of Rust as C++ for mortals. :)

Re: Dropbox’s Exodus from the Amazon Cloud

#58

Post by james_cowling »

SeanDav wrote: post #47
james_cowling wrote: post #44

Earlier quoted context omitted.

Yup, Dropbox Infra is mostly a Go shop. It's our primary development language and we don't plan to switch off any time soon. We're always about the right tool for the job tho, and there are definitely use cases where Rust makes a lot of sense. We've been really happy with it so far.

Without getting into any sort of religious war, what are typical use cases that make Rust a better choice?

I think @jamwt did a pretty good job of explaining this in https://news.ycombinator.com/item?id=11283688.

At a high level it's really a memory thing. There are a lot of great things about Rust but we're also mostly happy with Go's performance. Rust gave us some really big reductions in memory consumption (-> cheaper hardware) and was a good fit for our storage nodes where we're right down in the stack talking to the hardware.

Most of the storage system is written in Go and the only two components currently implemented in Rust are the code that runs on the storage boxes (we call this the OSD - Object Storage Device) and the "volume manager" processes which are the daemons that handle erasure coding for us and bulk data transfers. These are big components tho.

Re: Dropbox’s Exodus from the Amazon Cloud

#60

Post by jamwt »

dikaiosune wrote: post #48
jamwt wrote: post #45

Earlier quoted context omitted.

We use 3rd parties for the "obvious" stuff. Like, we're not going to reinvent json serialization. But we typically don't use any 3rd party frameworks on the backend. So things like service management/discovery, rpc, error handling, monitoring, metadata storage, etc etc, are a big in-house stack. So, we use quite a few crates for the things it makes no sense to specialize in Dropbox-specific ways.

Cool. This might be getting into the weeds a bit, but are you still on rustc-serialize for json or are you trying to keep up with serde/serde_json? If you're using serde, are you on nightly? From your comment above I got the impression that only using stable features was very important, so I'm curious how your codebase implements/derives the serde traits.

We're on rustc-serialize. JSON is not really a part of our data pipeline, just our metrics pipeline. So the performance of the library is not especially critical.
Post reply on HN