[deleted]
Things I learned from building a production database
41–50 of 112 posts
Re: Things I learned from building a production database
#42Assuming I'm not the only one who's never heard of Delos or Cubby: https://engineering.fb.com/2019/06/06/data-center-engineerin...
Chubby, not cubby. And I also thought it was weird that the author referred to a piece of Google internal infrastructure to describe a piece of Facebook internal infrastructure... how many non-{X,G}ooglers know what Chubby is?
From what I understand Chubby is basically etcd. So, Chubby, very few. The concepts behind it? Most of the people who work low level with kube.
Re: Things I learned from building a production database
#43Is a diff Facebook's equivalent of a feature branch or PR?
Isn't diff just a standard, generic term for a change difference? (Like in git: https://git-scm.com/docs/git-diff ) Someone correct me if I'm wrong, but if my memory is correct, I was under the impression that a pull request was a term coined in the early Github days specific to their PR feature.
Yes, diff is a generic name, after a Unix tool with the same name. However, it hadn’t been the most popular name for the self contained unit of changes, that you would send to others to review or apply — the “patch” was. In Linux git workflow, you would use the “git format-patch” command to generate patch to send to others for review and to apply it to their branch.
Re: Things I learned from building a production database
#44Earlier quoted context omitted.
author of the post here: apologies for the acronyms! I code-switched from academia/research to industry via FB a few years back and just picked up a bunch of terms that I thought were universal in industry. IC does mean Individual Contributor or "person that is not a manager" -- I'll add a definition on top!
I wonder if it says anything about Facebook's culture that I've never heard of the term Individual Contributor before. Everywhere else, it's Team Member or something along those lines indicating that you're not on your own.
“IC” is also commonly used at Google and at many other companies. It is by no means a Facebook thing.
Re: Things I learned from building a production database
#45Earlier quoted context omitted.
The first engineer on the Delos team here. This design decision gave us an edge: we delivered the first production cluster in 8 months by layering over existing systems ; and we smoothly migrated all underlying implementations in the following 2 years without our customer aware of it (0 downtime). This design decision is well captured by the OSDI’20 Virtual Consensus in Delos paper.
Very interesting. How did you deal with the issue where the old API had some feature X that wasn't supported in the new API but some customers depended on feature X?
I guess that a hard question for user facing API: you need to support both the old and the new features during the migration.
In our case, this design principle mostly applied to our internal APIs. Particularly, we designed our internal sub components (consensus protocol, particularly) in a way we can swap it without any downtime.
Re: Things I learned from building a production database
#46Is a diff Facebook's equivalent of a feature branch or PR?
A "diff" in Phabricator is roughly equivalent to a PR, yes. A single point-in-time collection of, well, diffs against head/master that get code-reviewed and committed as a unit. If you were at Google, you'd call it a "CL"
Re: Things I learned from building a production database
#47> [16] Design as a team; implement as individuals.
This is pithy. I'm curious - does anyone here follow this philosophy? How do you actually design as a team? A meeting for every single design decision?
I'm used to the team finding general alignment on the problem in meetings, but then a single person coming up with the design, writing a doc, and circulating it for comments.
Re: Things I learned from building a production database
#48> [16] Design as a team; implement as individuals. This is pithy. I'm curious - does anyone here follow this philosophy? How do you actually design as a team? A meeting for every single design decision? I'm used to the team finding general alignment on the problem in meetings, but then a single person coming up with the design, writing a doc, and circulating it for comments.
I guess the intent is to say, decide on the API interfaces and endpoints beforehand and implement to that spec.
Which is understandable, as you have to integrate anyway and doing it later is more painful than doing it earlier.
Re: Things I learned from building a production database
#49 Interface directly with customer ICs
====
what's IC?
Re: Things I learned from building a production database
#50Interface directly with customer ICs ==== what's IC?