Somebody asked me at a church picnic earlier this summer what I actually do for a living, and when I said “I build cloud architecture for large companies,” I watched their eyes do that thing where they’re still smiling but have already left the conversation. I even got a “that sounds interesting.”
I don’t blame them. “The cloud” has become one of those phrases everyone nods along to without anyone quite agreeing on what it means: is it a place? A company? A thing you buy? All three, kind of, which is exactly the problem.
So let’s fix that, without the acronym soup. You don’t need to understand cloud computing the way I need to understand it to do my job. You need to understand it the way you understand that your car runs on an engine, without needing to rebuild one: enough to make good decisions, ask good questions, and not get talked into things you don’t need.
The one-sentence version
Cloud computing means renting computers, and the software that runs on them, from someone else’s building instead of buying and running your own. Or to make it an even more T-shirt-sized sentence: “The cloud is your stuff running on someone else’s computers.”
That’s genuinely most of it. Instead of a company buying a server, plugging it into the wall in a back room, and hiring someone to keep it running, they rent that computing power from Amazon, Microsoft, or Google, who run enormous buildings full of servers and let thousands of companies share the capacity. You’ve almost certainly used this today already: your email, your streaming service, your banking app are all running on somebody’s cloud.
Not everything has to route through someone else’s servers, though. Some hardware is built specifically to skip the cloud entirely: I get into why that mattered to me picking a new 3D printer in The Sovol M1D: Backer Report.
The three letters that actually matter: IaaS, PaaS, SaaS
SaaS (Software as a Service) is the one you already use constantly and never think about as “cloud” at all. Gmail, Netflix, Slack, your online banking portal: you open a browser or an app, you use the thing, and you never once think about what server it’s running on. This is renting the fully-furnished apartment. You don’t own it, don’t choose the layout, and don’t get a say in what it looks like. You just pay for the use and someone else handles everything underneath.
PaaS (Platform as a Service) is one layer down, and it’s mostly relevant if you’re building software rather than just using it. It gives developers a ready-made environment to build and run applications without managing the underlying servers themselves. Think of it as renting a food truck instead of building a restaurant from scratch: the kitchen equipment is already there; you just bring the recipe.
IaaS (Infrastructure as a Service) is the rawest layer: literally renting virtual computers, storage, and networking, and you decide what runs on top. This is the empty plot of land. Maximum control, maximum responsibility, and it’s genuinely not something most people ever need to touch directly. If you’re not in IT, you can safely file this one under “things that exist” and move on.
For almost everyone reading this, SaaS is 95% of your actual cloud experience. The other two matter more if you run or work closely with a business that builds its own software, or needs its own environment.
The part that actually changes your decisions: public vs. private vs. hybrid
This is the distinction that shows up in real conversations, so it’s worth actually knowing.
Public cloud is what most people mean by default: shared infrastructure, owned by a big provider, used by many customers at once, like an apartment building. Private cloud is dedicated infrastructure used by just one organization, often for compliance or security reasons, the whole building, but you’re the only tenant and you pay accordingly. Hybrid is a mix of both, which is genuinely where most mid-sized and larger organizations actually end up living, whether that was the original plan or not.
If you’re a small business owner or just trying to make sense of what your IT provider is proposing, the question worth asking isn’t “should we be in the cloud”: you probably already are, in the SaaS sense, whether you meant to be or not. It’s “does this specific workload need dedicated, isolated infrastructure, or is shared infrastructure genuinely fine here?” Most of the time, for most workloads, shared is fine. The cases where it isn’t usually involve regulatory requirements: healthcare data, financial records, government contracts, where “shared” isn’t a technical problem so much as a compliance one.
What “the cloud” is not
It’s not one place. There’s no single building called “the cloud”: Amazon Web Services, Microsoft Azure, and Google Cloud are separate companies with separate data centers scattered across the globe, and “which cloud” you’re on matters more than people assume, the same way it matters whether your money is in a particular bank versus just “a bank.”
It’s also not automatically disaster-proof. Moving a workload to the cloud doesn’t outsource your responsibility for keeping it running when something goes wrong: a provider’s regional outage, an account compromise, or plain old ransomware can take cloud-hosted systems down just as hard as anything sitting in a back-room server closet. I get into what that actually means for backups and recovery planning in Backups vs. DR: Why You Need Both.
It’s also not inherently cheaper, which surprises people. Cloud computing trades a large upfront cost (buying servers) for an ongoing operating cost (renting capacity), and if nobody’s watching that ongoing cost, it can quietly balloon past what the hardware would have cost you outright. That’s a topic for its own post, but it’s worth knowing going in that “cloud” and “cheap” are not the same promise, even though they get sold that way.
So what should you actually take away from this?
If you’re evaluating a vendor pitch, a software purchase, or just trying to follow a conversation at work: ask which of the three layers (SaaS, PaaS, or IaaS) you’re actually being sold, because that tells you how much responsibility you’re taking on versus how much the vendor is handling for you. It’s the same instinct I’d point you toward when picking between Copilot, ChatGPT, or Claude: know what tier you’re actually paying for before you commit to it. And when someone says “we’re moving to the cloud” like that settles the conversation, it’s worth a follow-up question: which cloud, which layer, and why does this workload need to move at all?
That’s not skepticism for its own sake. It’s the same instinct you’d apply to any big purchase: understanding roughly what you’re buying before you sign. “The cloud” isn’t magic, and it isn’t one thing. It’s just somebody else’s very large building full of computers, rented out in a few different ways. Once that clicks, the rest of the jargon gets a lot less intimidating.
Here’s where most explanations go sideways: they throw all three of these at you at once like you’re supposed to instantly file them away. You’re not. You need to know they exist and roughly what separates them, because it explains why some cloud products feel like “rent an apartment” and others feel like “rent a plot of land and build the house yourself.”
And if you’ve actually landed in that other 5%: running your own applications, storing data at real scale, standing up something a development team needs to build and deploy on: the natural next question is which provider. I break that down for small businesses specifically in Azure vs. AWS vs. Google Cloud for Small Business.