[This post assumes some familiarity with Hyperledger Fabric. You can use it to test your understanding of HF.]

What are the top ten things I would tell someone about Hyperledger Fabric?

1. What is Hyperledger Fabric (HF)? HF is a strongly consistent decentralized database. If you are familiar with distributed databases like Cassandra, a decentralized database can be thought of as a distributed database where each node is an equal master. There are no followers or slaves. Further nodes are independently owned and operated by separate companies.
2. When to use HF? When you want to establish a system of record with other companies without giving up control of the database in hands of a single organization (or 3rd party intermediary / escrow). Every company has their independent copy of the database that remains in sync with other copies.
3. Above (#2) does assume a few things. That you will not make out of band changes to your copy of the database (ledger). Every change must go through the approved process (next bullet point).
4. All changes to the database happen after going through a formal process of propose, collect votes, commit. This is similar to how decisions are made in a board meeting by a board of directors in a company or organization.
5. In terms of CAP theorem, HF provides consistency at expense of availability in case of a network partition (one or more endorsing nodes becomes unreachable). An endorsing node is a node whose vote is necessary for a transaction to be committed.
6. The ordering service in HF establishes a global (i.e., total) order on transactions. It can be run on a single node (solo) or can be run on a cluster of multiple nodes to make it Crash Fault Tolerant (CFT). When run on a cluster, the Raft protocol is used to decide which node will be the next leader if the leader goes down (crashes). At any time, only one node is the leader. Rest are just followers.
7. Establishing a global order on transactions ensures all peer nodes commit them in same order. In this way the peer nodes always remain in sync. This assumes there are no undeterministic side effects in the chaincode producing a transaction.
8. There is no consensus protocol running on peer nodes. The consensus protocol (Raft) runs on nodes making up the ordering service.
9. Digital signatures and X.509 certificates are used throughout for proving identity (authentication) and access control (authorization).
10. You don’t know what version of the chaincode is running on peer nodes owned by other organizations. It may not be identical to the code you are running on your peer node. This is more of a security bug than a feature IMO.
11. Bonus: As consequence of above, when it comes to security and privacy you have to be wary of not just what data is stored on the ledger, but any data you are sending to the chaincode can be inspected by your peers.

For more tips, you can checkout my book.