Ryan Peterman

When you say that most people shouldn't, my immediate thought was that one of the big projects you worked on at Dropbox was migrating away from S3.

So why did Dropbox migrate away from S3?

Did S3 do any counter negotiation before you set out to leave them and say like, oh, you know, we'll cut you a deal.

Can you give an example of a tight understanding of your workload leading to like something you could do that S3 couldn't?

Yeah, when I was reading about this migration, I saw somewhere in the migration, you initially started with Go, and then the racks or something that you're running on the hardware itself was ooming too much or requesting too much memory.

And then you migrated to Rust.

The cascading failure you mentioned, was there... So that happened and then there was a postmortem.

I don't think we needed a postmortem.

When I worked on infrastructure at Instagram, we had this concept of DEFCON knobs, which are basically these configs that you could flip that would gracefully degrade your system, where you can still operate it, but maybe in the case of Dropbox, you store less replicas.

So you take on a temporary increase of risk in losing data because you need to.

Did you have something like that and did you flip it in that type of case never when it came to durability?

I see.

So S3 is kind of, um, it's like elastic storage.

When I looked at this project, it's such a massive migration.

And my first thought is how do you coordinate this whole project without breaking the system as it's running?

What are your thoughts on doing such a large migration without breaking things?

Okay, so it was double writing both systems for a while.

Okay, and then you switched over Reed's

You mentioned simplicity, and intuition-wise, it makes sense.

Do you have a concrete example, though?