Why Pure Hardware Speed Is Over: Embrace Distributed Systems Today

At the Intel Developer Forum 2005, CEO Craig Barrett publicly apologized for canceling the 4 GHz chip, signaling that the era of relying solely on vertical hardware performance is over and that distributed development has become mainstream.

What is often marketed as “cloud computing” is essentially a commercial packaging of distributed systems; many developers search for cloud‑computing material but end up finding only high‑level promotional content, while the real substance lies in the well‑known concept of distribution.

The simplest form of distribution adds a load‑balancer in front of multiple web servers, a cache server for temporary state, and a shared database. This basic architecture is illustrated in the diagram below.

In such a setup only the web servers are truly distributed, and they do not communicate with each other, making the structure and implementation very simple.

More demanding scenarios require distribution at every layer—load balancing, databases, caches, files, inter‑node communication, and extensive monitoring and management when the number of nodes grows.

A comprehensive distributed system can be composed of the following modules:

Distributed task processing service: handles specific business logic.

Distributed node registration and discovery: manages naming and physical information of all nodes, acting as a bridge between them.

Distributed DB: distributed structured data storage.

Distributed cache: non‑persistent distributed data caching.

Distributed file storage: distributed file access.

Network communication: data exchange between nodes.

Monitoring and management: collection, monitoring, and diagnosis of node status.

Distributed programming languages: languages designed for distributed environments such as Erlang or Scala.

Distributed algorithms: algorithms that solve problems unique to distributed settings, e.g., Paxos for consistency.

Understanding these components is essential for deep research into cloud computing and distributed systems, as each area demands low‑level knowledge.

It is useful to distinguish “cluster” (a physical collection of machines) from “distributed” (a working mode where a program runs across multiple machines). A cluster may or may not run distributed systems; a distributed system may span multiple clusters or independent machines.

Clusters focus on centralized management and improve availability by replicating the same service across machines. Distributed systems aim to reduce single‑point failures and balance load, but they introduce challenges such as consistency.

For example, a website like Sina can use a cluster: a front‑end server directs requests to one of several back‑end servers based on load.

In a narrow sense, distributed systems resemble clusters but are less tightly organized; if one node fails, only the specific service it provides becomes unavailable.

In simple terms, distributed systems shorten the execution time of a single task, while clusters increase the number of tasks processed per unit time.

If a task consists of ten independent sub‑tasks, a single server would need ten hours, whereas ten servers handling each sub‑task in parallel finish in one hour (the classic Map/Reduce model).

Clusters can be categorized into high‑availability, load‑balancing, and high‑performance computing clusters; distributed systems typically fall under the high‑performance computing category.

Distributed: different business modules deployed on separate servers or a single module split across servers to solve high‑concurrency.

Cluster: the same business deployed on multiple machines to improve system availability.

In everyday language, a single‑chef kitchen represents a cluster, while adding a dedicated prep chef creates a distributed workflow.