DS as a single coherent system

Justification

A distributed system is a collection of independent computers, connected by a network and running distribution middleware, that appears to its users as a single coherent system. Its components communicate and coordinate their actions only by passing messages (Tanenbaum; Coulouris).

The statement means that, although the system is built from many independent machines, the user and the application see one computer. This is achieved through the following features.

Features that give a single view

• Transparency: the user does not see where files are, which server answers, how many replicas exist, or when a node fails.
• Common middleware and uniform interface: the same API or protocol is used for all resources (for example a web browser).
• Resource sharing through a single name space (one file tree, one login).
• Concurrency control and consistency: many users work at once without seeing interference.
• Fault tolerance: failures are masked, so the service seems continuous.
• Scalability and openness: the system can grow while the view stays the same.

Example: when a user uses Google Drive, the files appear on one drive though they are stored and replicated over many data centres.

Challenges

• Network latency and partial failures cannot be fully hidden.
• Keeping replicas consistent and controlling concurrent access.
• Heterogeneity of hardware, OS and data formats.
• Security and trust over an open network.
• Scalability without bottlenecks.
• No global clock for ordering events.

Fundamental model

A fundamental model is an abstract description of the essential properties that all distributed systems share. It is used to reason about the design, to state what is and is not possible, and to prove correctness without implementation details. There are three:

• Interaction model: processes interact by messages, with communication delay, no global clock and clock drift. It is synchronous (known bounds on execution time, message delay, drift) or asynchronous (no bounds).
• Failure model: classifies faults as omission (process or channel fails to act), arbitrary/Byzantine (any behaviour) and timing (response outside the time interval).
• Security model: assumes an adversary who can send or read messages and so threatens processes and channels; defends with authentication, encryption and access control.