DISTRIBUTED SYSTEMS

Lecture 1: Introduction, Design Goals

& System Models
Course: Distributed Systems (SWE 06123225)

Md. Shymon Islam

Lecturer
Department of Computer Science and Engineering (CSE)
Shahjalal University of Science and Technology, Sylhet

Primary reference: Tanenbaum & van Steen, Distributed Systems: Principles and Paradigms, 2nd Ed.
 LECTURE 1 ROADMAP

Today's Agenda

What Is a Distributed System? Why Build One? Design Goals

01 02
Definition & the single-coherent-system idea Resource sharing, transparency, openness, scalability

Distribution Transparency Scalability & Pitfalls

03 04
The many faces of “hiding” distribution Growing pains and false assumptions

Types of Distributed Systems From Models to Architecture

05 06
Computing, information & pervasive systems First look at the client-server model

Distributed Systems | SWE 06123225 | Lecture 1

 CONCEPT 01

What Is a Distributed System?

EXAMPLE: THE WEB

“A collection of independent computers that appears to its users as
one coherent system.” Millions of servers worldwide, yet a user simply types a
URL and sees “one web.”

Two key properties:

1 Independent Computing Elements

Autonomous machines/nodes, each with its own hardware & OS.

2 Single Coherent System

Users see one logical system — the distribution is hidden.

“It's just the Web”

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 1.1, p. 2

 CONCEPT 02

Why Build Distributed Systems? — Design Goals

1 2 3 4

Resource Sharing Distribution Transparency Openness Scalability

Let users & apps access hardware, data, Hide the fact that resources are Offer services per standardized rules, Remain effective as the system grows in
and services across the network — distributed — the system should feel like enabling interoperability & portability size, geographic spread, or number of
printers, files, databases. a single machine. across vendors. domains.

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 1.2, p. 3

 CONCEPT 03

Distribution Transparency
The system hides different aspects of distribution from the user. ISO calls out eight forms:

1 2 3 4

Access Location Migration Relocation

Hide differences in data representation & how Hide that a resource may move to another
Hide where a resource is physically located Hide that a resource may move while in use
a resource is accessed location

5 6 7 8

Replication Concurrency Failure Persistence

Hide that a resource may be shared by several Hide whether a resource is in memory or on
Hide that multiple copies of a resource exist Hide the failure & recovery of a resource
users disk

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 1.2.2, pp. 4–7 (Fig. 1-2)
 CONCEPT 02B

Openness
An open distributed system offers services according to standard rules describing
syntax & semantics — enabling: KEY DESIGN PRINCIPLE

Interoperability Separate Policy from Mechanism

Two implementations from different vendors can co-exist & work together

A system is open largely because its components implement

well-described, standardized interfaces (mechanism), while
Portability the actual policy choices (e.g. caching strategy, consistency
level) are left configurable.
Applications built for one system can run on another without modification

Extensibility / Flexibility

New components can be added or existing ones replaced easily Typically specified via an Interface Definition Language (IDL).

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 1.2.3, pp. 7–9
 CONCEPT 04

Scalability
Three dimensions of scale: Scaling techniques:

1 Size
Hide Communication Latency
Adding more users/resources without noticeable loss of performance Use asynchronous communication; avoid waiting on every request

2 Geographical
Distribution
Users & resources may be far apart — latency becomes a problem Split a component into parts, spread across the system (e.g. DNS)

3 Administrative
Replication & Caching
Spans independently managed organizations/domains Duplicate resources near clients to increase availability & performance

Trade-off: caching & replication improve scalability but introduce consistency

problems (Ch. 7).

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 1.2.4, pp. 9–16
 CONCEPT 05

Pitfalls: 8 False Assumptions

Peter Deutsch's classic list of assumptions every developer makes the first time they build a distributed app — and shouldn't:

1 2 3 4

The network is reliable The network is secure The network is homogeneous The topology does not change

5 6 7 8

Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 1.2.5, p. 16

 CONCEPT 06

Types of Distributed Systems

Distributed Computing Systems Distributed Information Systems Distributed Pervasive Systems

HI GH-PE R FOR M ANCE COM PUT I NG E NT E R PR I S E APPL I CAT I ON I NT E GR AT I ON UBI QUI T OUS , E M BE DDE D COM PUT I NG

Cluster computing — homogeneous nodes, single

Transaction processing systems (ACID transactions) Mobile & sensor networks, home systems
admin (e.g. Beowulf)

Grid computing — heterogeneous, multi- Enterprise Application Integration — RPC, message Naturally distributed, resource-poor, unreliable
organization (virtual orgs) queuing, workflow nodes

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 1.3, pp. 17–30
 BRIDGING TO CHAPTER 2

From Models to Architecture

A system architecture describes how software components are organized & how they interact. Two complementary views:

Software Architecture System Architecture

Logical organization into components (architectural styles): layered, object- The actual physical/runtime placement of components on real machines —
based, resource-based, event-based, and combinations. where does each piece run?

Today's focus — the most fundamental system architecture: the Client-Server Model →

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 2.1, p. 34

 CONCEPT 07

The Client-Server Model

A centralized architecture where processes take on one of two roles:

Server
request
Waits for incoming requests, then acts on them & sends a response.

CLIENT SERVER
Client
reply

Sends a request to a server, then waits for the server's reply.

Multitiered Architectures

The interaction follows a simple request-reply behavior — no explicit 2-tier: client + server • 3-tier: client + application server + database server
acknowledgements needed (the reply IS the ack).

Distributed Systems | SWE 06123225 | Lecture 1 Book ref: Ch. 2.2.1, pp. 36–43
 WRAP-UP

Summary & Next Steps

Key Takeaways Reading Assignment

A distributed system hides its distribution behind one coherent interface Tanenbaum & van Steen, Distributed Systems: Principles and
Paradigms, 2nd Ed.

Four goals drive design: sharing, transparency, openness, scalability Chapter 1 (Introduction), pp. 1–30

Chapter 2.1–2.2.1 (Architectures → Client-Server), pp. 33–43

Scalability has 3 dimensions & comes with consistency trade-offs

Systems fall into computing, information & pervasive categories Next Lecture

The client-server model is our first building block for architecture

System Architectures: Decentralized & Peer-to-Peer Models,
Architectures vs. Middleware

Distributed Systems | SWE 06123225 | Lecture 1 Questions? Let's discuss.