What Cloud Computing Actually Is

Concept

Cloud computing is the delivery of computing resources - servers, storage, networking, databases, and higher level services - over a network, on demand, charged by what you actually consume.

The word that matters is on demand. Renting a server from a hosting company is not cloud computing if ordering it takes two days and a phone call. It becomes cloud computing when you can create it in seconds through an interface or an API, and destroy it just as fast, and pay only for the minutes it existed.

Why it is used

• No capacity guessing. You no longer have to predict how much hardware you will need in two years and buy it today.
• Speed. A server that once took weeks to procure, rack and configure now takes under a minute.
• Cost follows usage. A test environment that runs eight hours a day costs a third of one that runs continuously, because you can switch it off.
• Global reach. Deploying into another continent is a configuration choice, not a construction project.
• Someone else does the undifferentiated work. Power, cooling, physical security, hardware replacement and, depending on the service, patching and backups.

Architecture

Every cloud service is built on the same stack. Knowing which layer you are renting tells you what you are still responsible for.

Your application and your data          <- always yours
------------------------------------------------------
Managed services (databases, queues, functions)
Virtualisation and the control plane (APIs, scheduler)
Physical servers, storage arrays, network fabric
Data centre: power, cooling, physical security
------------------------------------------------------
                                        <- provider owns everything below your layer

The higher up the stack you buy, the less you operate and the less control you keep. That single trade off is the whole subject in one sentence.

The five characteristics that define a cloud

If a service is missing several of these, it is hosting with a modern logo on it.

Important terminology

The control plane and the data plane fail independently. A provider console outage can leave you unable to create new servers while your running application serves traffic perfectly. Knowing the difference stops a lot of panic.

Real world example

A college results portal is used heavily for three days each semester and barely touched for the rest of the year.

• Owned hardware: you must buy servers big enough for results day. For 362 days a year that capacity sits idle, and you paid for all of it up front.
• Cloud: you run two small servers most of the year, and scale to twenty for the three days that need them. You pay for the twenty for three days only.

Nothing about the application changed. What changed is that capacity became a dial rather than a purchase.

Commands

You can see cloud infrastructure from any terminal. These commands are read only and safe to run.

# Resolve a hostname to the addresses actually serving it
dig +short YOUR_DOMAIN

# Show the response code and how long the whole request took
curl -s -o /dev/null -w "code=%{http_code} time=%{time_total}s size=%{size_download}" https://YOUR_DOMAIN

# Show the response headers, which often name the platform or CDN
curl -sI https://YOUR_DOMAIN

Command options worth knowing

Hands on lab

1. Pick any public website you use.
2. Run dig +short against it and count how many addresses come back.
3. Run the curl -w command and note the total time.
4. Run curl -sI and look for headers naming a platform, a CDN or a cache status.
5. Repeat step 3 three times. The second and third runs are usually faster - explain why to yourself before reading on.

Expected output

$ dig +short example-site.test
203.0.113.41
203.0.113.87

$ curl -s -o /dev/null -w "code=%{http_code} time=%{time_total}s" https://example-site.test
code=200 time=0.412s

$ curl -sI https://example-site.test
HTTP/2 200
server: nginx
cache-control: max-age=300
x-cache: HIT

Two addresses for one name is load balancing. The faster repeat runs are DNS and TLS session reuse, not the site getting quicker.

What is not cloud computing

• A physical server in a rented rack that you ordered by email. That is colocation.
• A virtual machine on a monthly contract with a fixed size. That is virtual hosting, and it fails the elasticity and measured service tests.
• A server in your office called "the cloud server". Naming is not architecture.

Common mistakes

• Believing the cloud is automatically cheaper. It is cheaper for variable, short lived or unpredictable workloads. A server at constant full load for three years is often cheaper to own.
• Believing the cloud is automatically more reliable. Providers give you the ingredients for reliability. A single server in a single location is a single point of failure wherever it runs.
• Treating cloud servers like owned servers. Configuring a machine by hand and never rebuilding it throws away most of the benefit.
• Forgetting the meter is always running. Resources created for a test and left behind are the single most common source of surprise bills.

Security considerations

• Multi tenancy means isolation is enforced by software. Keep the parts you control - access keys, permissions, network rules - correct, because your neighbours are not your threat model, misconfiguration is.
• Anything reachable over a public network is reachable by everyone. Default to private and open deliberately.
• Never place a credential in a command you paste into a shared terminal, a screenshot or a repository. Use placeholders such as YOUR_ACCESS_KEY while learning.

Best practices

• Decide which layer of the stack you want to operate before choosing a service.
• Tag every resource you create with an owner and a purpose, from the very first one.
• Destroy what you create in a lab as soon as the lab ends.
• Set a billing alert before you create anything, not after the first invoice.

Interview questions

1. Define cloud computing in one sentence without naming a provider.
2. Name the five characteristics and give an example of a service that fails one of them.
3. What is the difference between the control plane and the data plane, and why does it matter during an outage?
4. Is cloud always cheaper? Justify your answer with a workload where it is not.

Mini assignment

Take one system you use daily - a college portal, a shop, a streaming service. Write half a page answering: which of the five characteristics can you observe from the outside, which layer of the stack its owners are most likely renting, and what evidence from dig or curl supports your answer.

Conclusion

Cloud computing is on demand, metered, pooled capacity that you create and destroy yourself. Everything later in this path - Linux, networking, containers, automation - is about using that capacity well.