What Is Cloud Computing?

Every application needs somewhere to actually run — a computer to execute the code, a disk to store data, and a network connection so people can reach it. Traditionally, a company bought that computer, put it in a room (or paid someone else to), kept it powered and cooled, and had someone on staff to fix it when a disk failed at 2am.

Cloud computing replaces "buy and run it yourself" with "rent it, already running, from someone who operates thousands of these at once." A provider like AWS owns the physical data centres, hardware, power, and cooling, and rents out slices of that capacity over the internet. You never see or touch the physical machine — you just use it, and pay for what you actually use.

The three boxes inside the cloud in the diagram above — compute, storage, and database — are exactly the AWS service categories the next lesson introduces.

Picture Karoo Retail, a small South African online store. Every year, they run a two-week sale where traffic jumps to ten times its normal level, then drops back to normal for the other fifty weeks.

The traditional approach: buy enough physical servers to survive the sale at peak load. Those same servers then sit mostly idle for the other fifty weeks — Karoo Retail paid for capacity it uses two weeks a year, and if the sale ever grows faster than expected, there's no way to get more capacity except ordering more hardware and waiting for it to arrive.

The cloud approach: Karoo Retail rents only the capacity it needs, when it needs it. In the two weeks before the sale, they request more capacity — it's available in minutes, not weeks — and afterwards they release it and stop paying for it. The infrastructure decision that used to take months of procurement becomes something closer to an on/off switch.

Cloud computing doesn't make good engineering optional. Karoo Retail's application still has to be built in a way that can actually take advantage of extra capacity when it's added — that's a real skill, and later modules in this course spend real time on it (scaling, load balancing, fault tolerance).

What changes is the shape of the decision:

• Cost moves from a large upfront purchase (capital expenditure) to an ongoing, usage-based bill (operating expenditure).
• "We need more capacity" becomes a request you can make and reverse in minutes, not a hardware order with a lead time.
• Physical maintenance — replacing failed disks, patching the operating system, network upkeep — is not something the customer does for the underlying hardware.

Put together, this gives a growing team a few real, practical advantages:

• Elasticity — capacity can grow or shrink to match actual demand, instead of being sized for a worst case that mostly never happens.
• Pay-as-you-go economics — you're billed for what you use, not for headroom sitting idle.
• Speed — new capacity is available in minutes, not the weeks a hardware order takes.
• Global reach — the same application can run closer to customers in different parts of the world without a company building its own data centre in each one.

None of these are free of trade-offs — later lessons in this module cover pricing and responsibility in more depth — but together they explain why cloud computing has become the default starting point for most new software projects.