A distributed system is a collection of networked processes that coordinate to provide a service. A cloud is one way to package that system: pooled resources, virtualization, self-service allocation, elastic capacity, and usage-based cost.
What changes after one machine
On one machine, a process can usually distinguish a local call from a crash. Across a network, silence is ambiguous: the peer may have failed, the message may be delayed, or the reply may be lost.
client ── request ──> server
X reply lost
Did the operation run? The client cannot know from timeout alone.This partial failure creates the central design problems: retries, duplicate effects, coordination, stale state, and failure detection.
In plain terms: in a distributed system, “I did not hear back” is not the same as “nothing happened.”
Why clouds help
Cloud platforms make resources programmable. Instead of buying for peak load, a team can acquire and release compute, storage, and networking as demand changes. The benefit is not automatically lower unit cost; it is faster provisioning, shared infrastructure, elasticity, and converting capital expense into operating expense.
Elasticity still needs application support. Adding instances does not help when state is pinned to one node, the database is saturated, or work cannot be partitioned.
Grids, clusters, and clouds
- A cluster is usually a coordinated set of machines under one administrative domain.
- A grid federates resources across organizations, often for large scientific jobs.
- A cloud exposes pooled resources and services through automated interfaces and an operating contract.
The boundaries overlap. The useful question is which failure, ownership, provisioning, and pricing assumptions the application inherits.
Safety and liveness
Distributed properties often fall into two groups:
- Safety: something bad never happens; for example, two clients never both own the same exclusive lock.
- Liveness: something good eventually happens; for example, a valid request eventually completes.
Retries may improve liveness while threatening safety through duplicate writes. Coordination may protect safety while reducing liveness during a partition.
Review card
- Networks introduce partial failure and uncertain outcomes.
- Cloud adds programmable pooling, elasticity, and an economic model.
- Elastic infrastructure does not make an unpartitionable application scalable.
- State assumptions matter more than product labels.
- Safety prevents bad states; liveness guarantees eventual progress.
Distributed system 是一組透過 network 協調並提供 service 的 process。Cloud 則把這種系統包裝成 pooled resource、virtualization、self-service allocation、elastic capacity 與 usage-based cost。
離開單機後有什麼不同
單機 process 通常能分清 local call 與 crash；跨 network 時，沉默有多種原因：peer 掛了、message 延遲，或 reply 丟失。
client ── request ──> server
X reply lost
operation 是否執行？只看 timeout 無法知道。這種 partial failure 產生 retry、duplicate effect、coordination、stale state 與 failure detection 等核心問題。
白話來說： 在 distributed system 裡，「沒有回覆」不等於「什麼都沒發生」。
Cloud 為什麼有用
Cloud 讓 resource 可程式化。團隊不必先按 peak load 購買，而能依需求取得或釋放 compute、storage、network。價值不必然是單位成本更低，而是 provisioning 快、infrastructure 共享、可 elasticity，並把 capital expense 轉為 operating expense。
Elasticity 仍需要 application 配合。State 綁在單一 node、database 已飽和，或工作不能 partition 時，多加 instance 不會有用。
Grid、cluster、cloud
- Cluster： 通常由單一行政 domain 管理、互相協調的 machines。
- Grid： 跨組織聯邦資源，常用於大型 scientific job。
- Cloud： 透過 automated interface 與 operating contract 提供 pooled resource／service。
界線可以重疊；更有用的問題是 application 繼承了哪些 failure、ownership、provisioning 與 pricing assumption。
Safety 與 liveness
- Safety： 壞事永遠不發生，例如兩個 client 不會同時持有同一 exclusive lock。
- Liveness： 好事最後會發生，例如 valid request 最終完成。
Retry 可能改善 liveness，卻透過 duplicate write 破壞 safety；coordination 保護 safety，也可能在 partition 時降低 liveness。
複習卡
- Network 帶來 partial failure 與不確定 outcome。
- Cloud 增加 programmable pooling、elasticity 與經濟模型。
- Elastic infrastructure 不會自動讓不可 partition 的 application scale。
- State assumption 比產品名稱重要。
- Safety 防止壞狀態；liveness 保證最終進展。