Classroom presentation controls
Introduction: Why We Need Multiple Computers, How They Work, and the Cloud Revolution
This unit introduces the journey of modern computing: how software outgrew single machines, how distributed networks solved the problem, and how cloud platforms made global infrastructure available to anyone with an internet connection.
Everything runs on a single laptop or server.
Your code, web server, and database all live on one machine. It is simple to build, cheap to run, and easy to debug.
The server CPU hits 100% and memory runs out.
You buy a bigger server with 32 CPU cores and 128 GB RAM (Vertical Scaling). It handles the traffic, but costs 10x more.
No single computer on Earth can handle the load.
The largest server money can buy crashes under peak traffic. The only choice left is to split the work across hundreds of networked computers (Horizontal Scaling).
| Feature | Scale Up (Vertical Scaling) | Scale Out (Horizontal / Distributed Scaling) |
|---|---|---|
| Basic Idea | Buy one bigger, more powerful server | Add many standard, affordable computers to a network |
| Hardware Cost | Gets exponentially expensive at high tiers | Grows linearly with affordable commodity machines |
| Maximum Limit | Hard ceiling (limited by physical motherboard size) | Virtually unlimited (can connect tens of thousands of nodes) |
| What Happens When It Fails? | Total outage (single point of failure) | Other nodes take over instantly with zero downtime |
| Software Complexity | Simple (code runs in one memory space) | Higher (must handle network messages and timeouts) |
The entire technology industry shifted from buying massive proprietary mainframes to building software that runs across large clusters of standard networked computers.
A distributed system is a collection of autonomous computers that communicate over a network by sending messages, while presenting themselves to users as a single, unified system.
Letting users and apps share hardware and data.
Allowing teams across the world to share storage drives, databases, expensive GPUs, and printers securely without conflicts.
Hiding the messy network details from users.
Hiding where files live, how many backup copies exist, or whether a server crashed so developers and users can focus on their work.
Using standard rules so different technologies work together.
Using standard protocols (like HTTP and JSON) so an iPhone app, a Python script, and a Java server can exchange data seamlessly.
Handling growth without slowing down.
Expanding from 100 users to 100 million users smoothly by adding more standard machines to the cluster.
Transparency means hiding physical network complexities so software feels like it runs locally:
| Transparency Type | What Is Hidden from the User | Real-World Example |
|---|---|---|
| Access | Differences in how different computers format numbers and files | Opening a file using the same function call on Linux and Windows |
| Location | Where a resource physically lives in the world | Typing google.com without knowing which city's server answered |
| Migration | Moving files or databases between machines while idle | A database moves to a new server during maintenance with zero user impact |
| Replication | That multiple duplicate copies of data exist | Saving a photo on the cloud and it automatically copies across 3 datacenters |
| Concurrency | That other users are reading and writing at the same second | Two people buying items in an online store without corrupting inventory counts |
| Failure | That a server crashed or lost power behind the scenes | A web request automatically re-routes to a backup server without an error page |
When connecting multiple processors, hardware engineers use two fundamental approaches: sharing one physical memory pool or giving each machine its own memory.
Multiple CPUs share one central memory bus. Any CPU can read any memory byte instantly. Very fast, but limited to 32–64 cores before the bus gets clogged.
Each computer has its own private RAM. To share data, they must send messages over network cables. Can scale to 100,000+ computers in datacenters.
In multi-core computers, how CPUs connect to physical memory banks determines how well the machine performs under heavy load.
All CPU cores connect to one central memory bus. Every core takes the exact same amount of time to read any memory location. Limitation: Adding too many cores creates memory traffic jams.
Each CPU gets its own local memory bank attached directly to its socket. Reading local memory is 3x faster than reading memory attached to another CPU socket over interconnect links.
This 3D model illustrates how computers in a distributed cluster connect across multiple paths rather than relying on one single central wire.
Click and drag to rotate the model. In a networked mesh, nodes communicate directly across independent routes. If one cable fails, traffic reroutes around the failure.
*Key Takeaway: Networked clusters eliminate central hardware bottlenecks.
One special operating system on every machine.
Hides everything, but requires every computer to run the exact same operating system. Failed in the real world because companies need different operating systems for different jobs.
Standard operating systems with networking tools.
Computers run normal Linux or Windows. Users manually log in to remote machines using SSH or file shares. Shows no transparency, but is very flexible.
A helper software layer on top of standard operating systems.
Runs on top of any standard OS to provide easy remote communication, database tools, and security across different platforms. This is how all modern web and cloud apps work.
Instead of developers writing complex low-level network code for every application, middleware provides ready-made building blocks for distributed systems.
Peter Deutsch identified eight false assumptions that lead to bugs in distributed software:
| False Assumption | The Real Truth | What You Must Do in Code |
|---|---|---|
| 1. The network never fails | Wi-Fi drops, cables get cut, routers restart | Always add timeouts and retry logic |
| 2. Data travels instantly | Signals take 50–150ms to cross oceans | Never freeze the user interface while waiting |
| 3. Bandwidth is unlimited | Network pipes get congested during busy hours | Send compact data formats like JSON or Protobuf |
| 4. The network is secure | Packets can be intercepted on open networks | Always use HTTPS and encryption |
| 5. Network structure never changes | Servers crash and new instances spin up | Use automated service discovery tools |
| 6. There is only one administrator | Data crosses multiple companies and clouds | Use standard authentication tokens |
| 7. Moving data costs nothing | Cloud providers charge fees for data egress | Keep data transfers minimal and efficient |
| 8. All computers are identical | Clients use iPhones, Androids, Windows, Linux | Use universal data formats |
A single distributed system connects many different kinds of devices: an iPhone (ARM processor), a laptop (x86 chip), and a cloud server running Linux. They store numbers differently and run different languages.
1. Data Serialization: In-memory objects are converted into standard text or byte strings (like JSON or Protocol Buffers) before sending them over the network.
2. Standard API Definitions: Clear rules define what data is sent and received so a backend written in Java can easily talk to a frontend written in JavaScript.
Having one machine handle all authentication.
Works for 100 users, but crashes when 100,000 try to log in at once. Solution: Run multiple login servers behind a load balancer.
Storing all user records on a single hard drive.
The disk becomes too slow to process all read/write requests. Solution: Shard data across multiple database servers.
Algorithms that require knowing the state of all nodes.
Asking 10,000 servers for their status creates huge network traffic. Solution: Have nodes communicate only with nearby neighbors.
In large systems with thousands of servers, hardware failures happen every day. A distributed system is designed to keep running even when individual servers crash.
A working JavaScript simulation showing how two independent servers send data over a network with simulated latency:
// Distributed Node Message Passing Example
class DistributedNode {
constructor(nodeId, networkLatencyMs = 15) {
this.nodeId = nodeId;
this.networkLatencyMs = networkLatencyMs;
this.localState = new Map();
this.peers = new Map();
}
registerPeer(peerNode) {
this.peers.set(peerNode.nodeId, peerNode);
}
async send(targetNodeId, message) {
const target = this.peers.get(targetNodeId);
if (!target) throw new Error(`Node ${targetNodeId} unreachable`);
// Simulate real network cable transit time
await new Promise(resolve => setTimeout(resolve, this.networkLatencyMs));
return target.receive(this.nodeId, message);
}
receive(senderNodeId, message) {
this.localState.set(message.key, message.value);
return {
status: "ACK",
receiver: this.nodeId,
appliedState: message
};
}
}
// Connect two separate nodes across regions
const nodeA = new DistributedNode("node-us-east-1", 10);
const nodeB = new DistributedNode("node-eu-west-1", 85);
nodeA.registerPeer(nodeB);
console.log("Sending data across network...");
nodeA.send("node-eu-west-1", { key: "cluster_config", value: "replicated" })
.then(res => console.log("Response:", JSON.stringify(res)));Sending data across network...
Response: {"status":"ACK","receiver":"node-eu-west-1","appliedState":{"key":"cluster_config","value":"replicated"}} In the early 2000s, Amazon built massive server clusters to handle the huge surge of holiday shopping traffic during Black Friday and Cyber Monday.
Starting a software company required $100,000+ in hardware.
You had to buy physical servers, sign a 3-year datacenter lease, wire cables, and wait 8 weeks for hardware delivery before writing a single line of production code.
A student with a credit card has the same power as Netflix.
Anyone can launch 50 global servers in 60 seconds for a few dollars. If the project succeeds, it scales instantly; if it fails, you delete the servers and owe nothing more.
Microsoft, Google, and others joined the market.
Microsoft launched Azure and Google launched Google Cloud Platform (GCP). Today, over 90% of global internet traffic runs through cloud provider datacenters.
Cloud computing means renting computing power, storage space, and software over the internet from providers (like AWS, Azure, or Google Cloud), instead of buying physical computers yourself.
The National Institute of Standards and Technology (NIST) defines five traits that a service must have to be considered a true cloud:
Renting blank virtual computers, hard drives, and network wires.
You choose the operating system (like Ubuntu Linux) and install everything yourself.
Examples: Amazon EC2, Google Compute Engine, DigitalOcean.
Renting a managed environment ready to run your code.
You upload your code (Node.js, Python, Java). The provider handles the servers, OS updates, and auto-scaling.
Examples: Heroku, AWS Elastic Beanstalk, Vercel.
Using complete applications directly in your browser.
You don't manage any servers or write code. You just log in and use the finished web application.
Examples: Google Docs, Gmail, Microsoft 365, Canva.
IaaS gives you the most control. You get a raw virtual machine and can configure it however you want.
With PaaS, developers focus purely on building their application code without worrying about server operating systems or updates.
| Layer | Your Own Datacenter | IaaS (e.g. AWS EC2) | PaaS (e.g. Heroku) | SaaS (e.g. Google Docs) |
|---|---|---|---|---|
| Your Data & Files | You Manage | You Manage | You Manage | You Manage |
| User Logins & Passwords | You Manage | You Manage | You Manage | You Manage |
| Application Code | You Manage | You Manage | You Manage | Cloud Provider |
| Runtime & Database Updates | You Manage | You Manage | Cloud Provider | Cloud Provider |
| Operating System Patches | You Manage | You Manage | Cloud Provider | Cloud Provider |
| Physical Hardware & Power | You Manage | Cloud Provider | Cloud Provider | Cloud Provider |
No matter which cloud model you use, your data and user passwords are always your responsibility. If you give a user a weak password, the cloud provider cannot prevent unauthorized logins.
Rented servers shared securely with other customers.
Lowest cost, instant setup, and virtually unlimited capacity. Maintained entirely by companies like AWS, Microsoft, or Google.
Best for: Startups, web applications, mobile backends.
Dedicated servers used only by one organization.
Can live in your own company building or in a private datacenter rack. Maximum privacy, but expensive to build and maintain.
Best for: Banks, defense organizations, hospitals.
Linking an on-premises private cloud to a public cloud.
Keep sensitive customer records in your private datacenter, while running public web servers on AWS that expand during busy days.
Best for: Established enterprises migrating gradually.
Using services from two or more cloud providers at once.
Running parts of your app on Google Cloud and parts on AWS so your business stays online even if one provider has an outage.
Best for: Large corporations avoiding single-vendor lock-in.
Cloud bursting is a hybrid cloud technique where normal daily traffic runs on private company servers, but when traffic spikes unexpectedly, extra requests "burst" to rented public cloud servers.
| Type of Organization | Primary Need | Best Cloud Model Choice |
|---|---|---|
| Tech Startup | Needs to launch fast with zero upfront capital | Public Cloud (Serverless or PaaS) |
| Commercial Bank | Must follow strict data residency laws | Private Cloud on-premises |
| E-Commerce Retailer | Normal sales daily, huge Black Friday rush | Hybrid Cloud with Cloud Bursting |
| Hospital / Healthcare | Needs medical record privacy and offsite backups | Private Cloud with encrypted Hybrid backup |
| University Research Lab | Huge batch computing runs once a month | Public Cloud Spot/Preemptible GPU instances |
The biggest financial difference in cloud computing is moving from buying assets upfront (CAPEX) to paying for usage as an ongoing expense (OPEX).
A JavaScript calculation comparing the total 3-year cost of buying hardware versus renting cloud instances:
// Comparing On-Premises Cost vs Cloud Utility Cost
function compareCosts({
onPremHardwareCost, // Upfront cost to buy physical servers
datacenterOpexYearly, // Power, cooling, and building rent
cloudMonthlyCost, // Monthly pay-as-you-go cloud bill
years = 3
}) {
const onPremTotal = onPremHardwareCost + (datacenterOpexYearly * years);
const cloudTotal = cloudMonthlyCost * 12 * years;
const difference = cloudTotal - onPremTotal;
return {
onPremisesTotal: onPremTotal,
cloudTotal: cloudTotal,
cheaperOption: difference < 0 ? "Cloud" : "On-Premises",
yearlyDifference: Math.abs(difference / years)
};
}
const result = compareCosts({
onPremHardwareCost: 120000,
datacenterOpexYearly: 45000,
cloudMonthlyCost: 6200,
years: 3
});
console.log("3-Year Cost Comparison:", JSON.stringify(result, null, 2));3-Year Cost Comparison: {
"onPremisesTotal": 255000,
"cloudTotal": 223200,
"cheaperOption": "Cloud",
"yearlyDifference": 10600
} Start in minutes instead of waiting months.
Ordering physical servers takes 8 to 12 weeks for delivery and wiring. Cloud servers start in under 60 seconds from any laptop.
Grow when busy, shrink when quiet.
Automatically add servers during day peaks and turn them off at night, avoiding paying for idle computers.
Automatic multi-datacenter safety.
Cloud providers replicate data across separate buildings with independent power supplies to protect against floods and fires.
No internet means no access to your servers.
If your office loses its internet connection, work stops. Factory robots and medical devices cannot rely entirely on cloud due to network drops.
Hard to switch providers once you build deeply.
Using proprietary features from one provider makes moving to another provider difficult and expensive later.
Other tenants sharing the same physical machine.
If another company on your physical server runs a heavy calculation, your server might experience temporary slow-downs.
Rules about where citizen data is stored.
Many countries have laws requiring citizen and bank data to stay physically inside their national borders.
Preventing accidental runaway bills.
Because cloud scales automatically, a software bug can accidentally start 500 servers and generate a huge surprise bill.
Securing microservices without old office firewalls.
Systems must check authentication on every single message using secure keys, because servers talk over open networks.
| Service Type | What You Rent | What You Manage | Billing Method |
|---|---|---|---|
| IaaS | Virtual machines, storage, networks | Operating system, database, code | Per second of CPU and RAM |
| PaaS | Managed application runtime | Application source code only | Per active application instance |
| SaaS | Complete web software | Your own user settings and accounts | Per user per month |
| Serverless (FaaS) | Event-triggered code functions | Individual function code only | Per millisecond of execution |
This 3D model illustrates how modern cloud microservices connect into resilient mesh networks across datacenters.
Click and drag to inspect the shape. In a cloud mesh, services talk directly to each other without depending on one single bottleneck server.
*Multiple network paths allow services to stay connected even if individual links fail.
How hardware layers build upward into cloud software services.