Hardware Basics #1: Four Resources That Run a Computer — CPU, Memory, Storage, Network

When you run servers, you keep hitting the same questions. Why is this server slow? Why is this instance so expensive? Why is a service that was fine yesterday lagging today? The answer almost always narrows down to one of four things: CPU, memory, storage, and network. This series covers those four physical resources from an operator’s point of view, and by the end it shows how they surface as the spec sheet of a cloud instance.

Posts on Linux, Docker, and AWS assume you already know these four resources. This series fills in that assumption. It isn’t about picking parts or building a PC — it’s about where performance and cost are actually decided on servers and in the cloud.

Hardware Basics is grouped into 9 posts. This is the starting point.

Why you should understand hardware #

These days you rarely touch a physical server. Picking an EC2 instance, tuning a database’s memory value, choosing a disk type — all of it ends in a few console clicks. So it’s easy to leave hardware as a black box and move on.

The trouble is that performance and cost are decided inside that black box. Why a c5.xlarge costs what it costs, why a gp3 disk differs from an io2, why a server is still slow after you added memory — without understanding hardware, you can only guess. Understand how the four resources behave and “slow” and “expensive” stop being guesses and become things you can diagnose.

The four resources #

A computer is, in the end, four resources cooperating. Each has a different job, and each shows different symptoms when it runs short.

CPU — handles computation #

The CPU is the part that actually computes. Every operation, branch, and data transformation in your code happens here. When the CPU runs short, work queues up, and requests wait behind that queue. Its internals are the subject of #2.

Memory (RAM) — working space for data in use #

For the CPU to compute, the data has to be nearby. That nearby working space is RAM. It’s fast but volatile — its contents vanish when the power goes off — and its capacity is limited. The moment memory runs short, the system starts borrowing the slow disk as makeshift memory, and performance falls off a cliff. That’s the subject of #3.

Storage — keeps data with the power off #

Storage holds data permanently. Unlike RAM, its contents survive a power-off, but it’s far slower than RAM. Database files, logs, and uploaded images all live here, and speed varies widely by type (HDD / SSD / NVMe) and layout (RAID). That’s #4 and #5.

Network — the path to the outside #

No service ends at a single server. It constantly exchanges data with users, databases, and other services, and that path is the network. Wide bandwidth can still be slow if the distance is long, and that distinction trips people up in operations. #6 sorts it out.

One web request passes through all four #

The four resources don’t work in isolation; they cooperate in turn within a single request. Let’s follow a simple request: a user opening a product detail page.

User's browser
   │  ① Network — request reaches the server
   ▼
Web server (CPU/memory)
   │  ② CPU — parse the request, run the logic
   │  ③ Memory — hold the data being processed
   ▼
Database
   │  ④ Storage — read the product data from disk
   │  ⑤ Memory — frequently used data comes straight from cache
   ▼
Build the response (CPU/memory)
   │  ⑥ Network — response travels back to the user
   ▼
User's browser

If any one of the six steps is slow, the response time the user feels grows by that much. Slow disk leaks time at ④, insufficient CPU at ②, low memory at ③, and long distance at ① and ⑥.

The bottleneck forms in one place #

This is the most important principle of performance. Overall speed is set by the single slowest point. However fast the CPU is, if a request blocks on a disk read, that request is bound to disk speed.

That’s why bumping the spec blindly often does nothing. If the CPU is the bottleneck and you add memory, cost rises and speed stays put. The order is to measure which resource is the bottleneck first, then reinforce only that one.

CPU 8 cores   Plenty of memory   Slow disk (HDD)   Plenty of network
   fast            fast            ← bottleneck         fast

→ Swap the disk for an SSD and the bottleneck disappears,
   and the next-slowest resource becomes the new bottleneck.

A bottleneck moves to the next resource once you solve one. Performance work means tracking down that bottleneck and resolving it one step at a time.

CPU and memory are apart #

Almost every computer today follows a structure where the place that computes (the CPU) is separate from the place that holds data (memory). The CPU fetches instructions and data from memory, computes, and writes results back to memory. This round trip happens endlessly.

One important fact falls out of this: the CPU is far faster than memory. So the CPU tends to waste time waiting on memory, and to close that gap it keeps a small, fast store of its own — the cache. Why the cache governs performance is something #2 and #3 carry forward.

Common misconceptions #

“More cores always means faster” #

No. A task speeds up only if it can split across multiple cores. A single-threaded task runs at the same speed on 8 cores as on 1. #2 covers this in detail.

“More memory means faster” #

Only partly. Short memory definitely slows you down, but adding more once you already have enough doesn’t make things faster. Memory is less a resource that raises speed and more one that creates a cliff when it runs short.

“Bigger storage is faster storage” #

Capacity and speed are different axes. A 1 TB disk isn’t necessarily faster than a 100 GB one. Speed is set by type (HDD / SSD / NVMe) and IOPS. #4 draws the line.

“I can tell the cause by feel” #

The most expensive misconception. Which of the four is the bottleneck can only be known by measuring. Bumping the spec on a guess usually only grows cost while the bottleneck stays.

Wrap-up #

What we covered:

• A server’s performance and cost are decided by four resources: CPU, memory, storage, network.
• CPU computes, memory is working space, storage keeps data permanently, network is the path to the outside.
• One request passes through the four in turn, and the single slowest point sets the overall speed.
• Performance work is measuring bottlenecks and resolving them one at a time. Bumping the spec on a guess only grows cost.
• These four resources reappear at the end of the series as the spec sheet of a cloud instance.

Next — CPU #

Let’s go one level deeper into the CPU, the resource that handles computation. #2 CPU — Cores / Threads / Clock / Cache, and what a vCPU really is covers the difference between cores and threads, why clock speed alone can’t compare performance, how cache governs speed, and what the cloud actually means by a vCPU.