Cloud Concepts & Service Models

You already live in the cloud. The email you checked this morning, the photos backing up from your phone, the document a colleague shared, the show you streamed last night - all of it ran on computers you will never see, in buildings you will never visit, billed by the sip. You are fluent in using the cloud. You are probably just not fluent in explaining it. That gap is worth closing, because the explanation is short and it makes you sharper in every conversation where the word comes up.

The whole idea, in one breath

The cloud is renting computing instead of owning it. Servers, storage, software - you get a slice over the internet, on demand, and you pay for what you use. That is the entire concept. Everything else is detail.

The reason this matters is best seen by contrast. The old way was to buy computers. You guessed how much you would need, bought hardware for the busiest day you could imagine, installed it in a room, cooled it, secured it, patched it, and replaced it every few years. You paid up front for a guess, and most of that capacity sat idle most of the time. The cloud flips it: you rent what you need, when you need it, and you stop paying when you stop using it. It is the difference between buying a car and calling a ride. Both get you across town; the commitment and the cost shape are completely different.

There is a tidy way to test whether something is really cloud. Genuine cloud is on-demand (you get it yourself, in minutes), elastic (it grows and shrinks with your needs), and metered (you are billed by usage, like electricity). If a service lacks those, it is ordinary hosting wearing a nicer label. This is not just my framing; it mirrors the most durable neutral definition, written by the U.S. standards body NIST back in 2011, which lists five characteristics - self-service, broad network access, shared resource pools, rapid elasticity, and measured usage. You do not need to memorise the list. You need the gut feel: get it yourself, scale it freely, pay by the sip.

Three ways to rent

Once you accept that the cloud is rented computing, the only real question is: rented at what level? There are three answers, and a pizza makes them obvious.

If you cook a pizza entirely at home, you bought the oven, the flour, everything. That is the pre-cloud world. Take-and-bake hands you ready dough to finish in your own oven - that is renting raw infrastructure, the model called IaaS. You get bare virtual machines and storage and you install your software on top. Delivery brings the pizza cooked, though you still set the table - that is renting a platform, called PaaS, where you push your code and the provider runs and scales it for you. A restaurant just feeds you and washes up - that is finished software, SaaS, the kind you use through a browser every day, like web email or shared documents.

The pattern is the only thing you must remember. As you move from IaaS to PaaS to SaaS, you manage less and you control less, but you get to value faster. And in every single one of those models, your data stays your responsibility. The provider handles more of the machinery as you climb, but never your information and never who is allowed to touch it.

Where it lives, and who shares it

There is one more axis, and it is simpler than it sounds. Public cloud means you share the provider’s hardware with lots of other customers, safely separated - this is what most people mean by “the cloud,” and it is the cheapest, fastest place to start. Private cloud means hardware dedicated to one organisation, which costs more and scales slower but gives maximum control - the choice of banks and hospitals with strict rules. Hybrid cloud is a deliberate mix of the two, keeping the sensitive parts private while using public cloud for everything else.

For almost anyone starting out, the answer is public. Private and hybrid exist to solve specific problems - a law about where data may live, an old system that cannot move - not to be a default.

How to decide, every time

Here is the whole decision compressed into a habit. When you face a real need, ask: does finished software already do this? If yes, use it - that is SaaS, and you should not rebuild what you can buy. If not, are you running your own app and would rather not babysit servers? That is PaaS. Do you genuinely need control of the operating system, or are you moving an existing server as-is? That is IaaS. And unless a real rule forces your data somewhere specific, run it in public cloud.

Then add two safety habits, because the cloud’s pay-as-you-go nature rewards attention and punishes neglect. First, before you build anything, set a budget alert so a forgotten resource cannot quietly drain money - the classic beginner bill comes from something left running. Second, turn on multi-factor authentication on your account, because protecting access is always your job, not the provider’s.

The takeaway

You do not need to become an engineer to think clearly about the cloud. Hold three things: the cloud is rented, on-demand, metered computing; you can rent it as raw infrastructure, a platform, or finished software, trading control for convenience as you go; and you start in public cloud, on a free tier, with a budget alert and a strong login. With that, you can read any provider’s menu, follow any cloud conversation, and make a sensible first decision - all before your coffee goes cold.