What's the Good News?

The bottom line is that, despite the failure, uncertainty, and lack of specialized hardware support, we can build and effectively use systems that are an order of magnitude more powerful. In fact we can do this while providing a more available, more robust, more convenient solution. This semester, we'll learn how.

Measures of Quality

In building a distributed system to attack a particular problem, what are our specific measures of quality? What are the characteristics of a good system?

Just as there isn't one "perfect fod" for all people and all occasions, our goals in implementing a distributed system may vary with the particular problem. But, the following are some very typical and common measures of quality in distributed systems:

• Efficiency: Resources should perform productive work whenever possible.
  
  
• Convenience: The user should be free to apply the system to one or more tasks, with as little overhead as possible.
  
  
• Robustness: The system should be resiliant to failure. Failures should have as little an impact on the system's ability to perform useful work as possible.
  
  
• Availability: A user should be able to harness the utility of the system with as few barriers as possible. For example, users should not be bound to an unavailable instance of a resource, when an equally capable resources is available.
  
  
• Consistency: see below
  
  
• Coherency: see below
  
  
• Transparency: see below

Consistency vs. Coherency

Although these two terms actually mean very different things, they are often interchanged or used as synonyms. Although this practice isn't descriptive, it is common place -- please don't be surprised.

Different processes are said to have a consistent view of data, if each process sees the same value. If different processes see different values, they are said to have an inconsistent view of the data. Inconsistencies often arise as the result of replication. For example, if each process uses its own private replica of the data, one process might not see another process's changes. This could result in an inconsistent view.

Later we'll see that constantly maintaining atomic consistency, a.k.a. perfect consistency, is very, very expensive, and often not required in a particular application. For this reason, we often will select a more relaxed consistency model that describes when the data values can diverge, without generating incorrect results. But more on this later in the semester...

Data is said to be incoherent if it is the result of a collection of operations that make sense sense individually, but not collectively.

Transparency

A distributed system should hide the machinery from the user and present a unified interface that provides the features and hides the complexity. To the extent that this illusion is achieved, we say that transparency is achieved. No useful real-world system achieves complete transparency, so we often talk about the transparency of particular characteristics or features of a system. And even when discussing a particular feature or characteristic, there are many shades of gray. A few examples are given below:

• access transparency -- the user should have the same view of the system regardless of how she or he access it. For example, consider a user accessing the system locally versus remotely, or on her or his workstation versus another machine on the system.
  
  
• location transparency -- the user should need to know or care where resources are located -- they should just be accessible.
  
  
• migration transparency -- user's should know or care if resources or processes move -- they should function exactly as they did before.
  
  
• concurrency transparency -- concurrent operation should not result in noticable side-effects.
  
  
• failure transparency -- the user should not notice failures. The system should function as before (fail-safe) or should suffer only in performance (fail-soft).
  
  
• revision transparency -- software and hardware upgrades should not interrupt service or generate user-visible incompatibilities.
  
  
• scale transparency -- the system should be able to grow without noticable side-effects. It should be as good for small systems as large ones.