Understand the cloud — before you pick a provider.

Strip away the buzzwords and the cloud is simple: instead of buying and running your own computers, you rent computing — servers, storage, software — from a provider over the internet, and pay only for what you use.

Think of electricity. You do not build a power station to light your house — you plug into the grid and pay for what you consume. The cloud did the same for computing: it became a utility you tap into, not a thing you own.

Not every rented server is "the cloud". The widely-agreed definition (from NIST) lists five essential characteristics — worth knowing because they come up everywhere:

• On-demand self-service — you provision resources yourself, instantly, no phone calls.
• Broad network access — reachable over the internet from any device.
• Resource pooling — the provider serves many customers from shared infrastructure.
• Rapid elasticity — scale up or down quickly as needs change.
• Measured service — usage is metered, so you pay only for what you use.

Three shifts explain why the cloud took over computing in barely fifteen years:

• No upfront cost — turn a huge capital purchase into a small monthly bill. Anyone can start.
• Speed — an idea can be live to real users in an afternoon, not after months of buying and setting up hardware.
• Scale on demand — handle ten users or ten million with the same system, paying in proportion.

Clouds are sold in three main "service models", and the classic way to understand them is making pizza.

• IaaS (Infrastructure as a Service) — the provider gives you the kitchen (servers, storage, network); you cook everything. Most control, most work.
• PaaS (Platform as a Service) — the provider gives you a ready kitchen and ingredients; you just make the pizza (your app). They handle the ovens.
• SaaS (Software as a Service) — the pizza is delivered ready to eat. You just use the finished software.

Two modern ways to run code that go beyond the classic three models:

Containers package an app with everything it needs into one portable box that runs the same everywhere (you will meet Docker in the DevOps course). Serverless goes further: you write just a function, and the provider runs it only when needed — you do not think about servers at all, and you pay nothing when it is idle.

The practical rule: let the provider manage as much as you can tolerate. Every layer you hand off is a layer you no longer have to patch, secure and babysit — time your small team can spend on the actual product.

Choose IaaS when you need full control or must run specific software. Choose PaaS or serverless for most standard web apps. Choose SaaS when good software already exists and you do not need to build it.

Where does the cloud physically live? Four deployment models:

• Public cloud — shared infrastructure run by a provider (AWS, Azure, GCP). What most people mean by "the cloud".
• Private cloud — cloud technology dedicated to one organisation, often for strict control or regulation.
• Hybrid — a mix of private and public, connected together.
• Multi-cloud — using more than one public provider at once.

For almost everyone starting out — and for almost every African business — the answer is public cloud: no hardware, lowest cost, fastest start.

Three providers dominate the public cloud. They do similar things with different names:

• AWS (Amazon) — the largest, widest range of services, most jobs. The safe default to learn first.
• Microsoft Azure — strong in enterprises and governments already using Microsoft; great if your target employers are big organisations.
• Google Cloud (GCP) — strong in data and AI, clean developer experience.

Every provider splits the world into regions (geographic areas) and zones (separate data centres within a region). You choose where your resources run, and it matters for two reasons: latency (closer to users = faster) and resilience (spread across zones so one failure does not take you down).

Compute is the processing power that runs your programs. Every cloud offers a ladder of it, from most control to least management:

• Virtual machines — full computers you control (AWS EC2, Azure VMs, GCP Compute Engine).
• Containers — lightweight packaged apps, often orchestrated by Kubernetes.
• Serverless functions — run code on an event, no server to manage.

They are the same idea wearing three different provider names. Recognising that is the whole point of a fundamentals course — the vocabulary changes, the concept does not.

Clouds offer three broad kinds of storage, each for a different job:

• Object storage — for files: images, videos, backups (AWS S3, Azure Blob, GCP Cloud Storage). Cheap, massive, accessed by URL.
• Block storage — disks attached to virtual machines, like a hard drive.
• File storage — shared network drives for several machines.

Networking connects everything: a private network (VPC) isolates your resources, firewalls control what traffic is allowed, and load balancers spread traffic across several servers. Databases come managed by every cloud — relational (structured data: orders, users) and NoSQL (flexible, huge scale) — so you run a serious database without being a database administrator.

The most important security idea in the cloud: responsibility is shared. The provider secures the cloud itself — the buildings, hardware and core network. You secure what you put in it — your data, your accounts, your access settings, your configuration.

Most cloud breaches are not the provider being hacked. They are a customer leaving a storage bucket public or a key exposed. Knowing where your responsibility begins is the first step to not becoming that story.

Every cloud controls access through IAM (Identity and Access Management), and every cloud preaches one principle: least privilege — give each person and each service only the access it genuinely needs, and nothing more.

Two more non-negotiables. Encryption scrambles your data so it is useless if stolen — clouds encrypt data at rest (while stored) and in transit (while moving), often by default. Backups are copies that let you recover from a mistake, an attack, or a failure.

The cloud’s great strength — paying only for what you use — is also its great trap: costs can creep up quietly. Three habits keep you safe: set a budget alert on day one, turn off what you are not using (an idle server still bills), and right-size (pick resources that match real need, not the biggest "to be safe").

Once something is live, you must be able to see its health. Every cloud offers monitoring (metrics like CPU and request rate), logging (the detailed record of what happened), and alerts (a message when something crosses a line). Watch the four "golden signals" of any service: latency, traffic, errors, and saturation.

Let us assemble everything into one picture. A typical, sensible cloud setup for a real web app:

• Compute running your app (a managed platform or containers)
• A load balancer in front, spreading traffic
• A managed database for structured data
• Object storage for files and user uploads
• IAM with least-privilege access, and encryption on
• Monitoring and alerts, plus automatic backups
• A budget alert guarding the bill