What Cloud Computing Actually Is: The Honest First Lesson

Drawings of the cloud point up, at a soft shape in the sky, and explain nothing. The real answer has a standards-agency definition, a countable number of buildings behind it, and a history whose dates you can check. This article accompanies the Whiteboard Architect lesson that opens the cloud computing series: watch the full episode on YouTube for the boards drawn in real time, or read on: every number below links to the page it was verified against.

Cloud computing, defined without the sky

The industry says the cloud when it means the network, and the network in question is the Internet; cloud computing is the arrangement in which the machines and the software live elsewhere and you reach them across it. Your side shrinks to whichever device and browser is at hand.

The catalog of what cloud computing rents out runs the full height of the stack. Servers arrive as virtual machines or as dedicated hardware; storage, networking, and databases come alongside them; above those sit development platforms, and at the top entire applications that a team never installs at all, provisioned while you wait.

The NIST definition of cloud computing, and its arithmetic

Vendors describe the field in whatever way flatters their product, so the sentence worth memorizing comes from a standards body. NIST Special Publication 800-145, dated September 2011, calls cloud computing “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources.” The paper then does the counting that keeps the field organized, and its numbers are exact: five essential characteristics, three service models, and four deployment models.

Treat the enumeration as a checksum: a tutorial advertising four characteristics has slipped against the definition it means to teach. The five characteristics are deep enough material for their own episode later in this series; the present lesson carries the definition, the models, and the corrections.

What are the five essential characteristics?

The paper lists them: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. In its own definitions, a consumer can provision computing capabilities automatically, without human interaction with the provider; the network carries the capabilities to thin or thick client platforms; the provider’s pool serves multiple consumers on a multi-tenant model; provisioning scales outward and inward with demand; and usage is monitored, controlled, and reported.

The buildings behind the joke

Behind cloud computing sits physical plant, and the plant has a size. The buildings are hyperscale data centers: 1,136 were operating worldwide at the end of 2024, twice the count of five years earlier, typically thousands of servers to a building. Amazon Web Services, Microsoft Azure, and Google Cloud hold roughly 59 percent of all hyperscale capacity between them.

Numbers of that size are why an old joke lands. People say the cloud is just someone else’s computer, and the ownership half of the gag is accurate: the machines, the buildings, and the staff running them all belong to the provider. The alternative to renting is on-premises computing, in which an organization finances its own hardware in advance, installs it, and replaces it as it ages. AWS’s definition page compresses the difference into a swap of up-front capital expense for a metered bill.

Why do people repeat the joke that the cloud is someone else’s computer?

Because the ownership half of the sentence is true. The servers, the buildings, and the people who maintain both belong to the provider, at a scale few single organizations can match: a hyperscale facility typically packs in thousands of servers and operates as a building with its own physical security. Where the gag misleads is the implication that nothing else changed. A machine room rented by the hour arrives wrapped in professional operations, and the scale of those operations is what moves the unit price below anything one organization reaches alone.

The board in the video draws the same split: a crossed-out cloud on one side, the promise of a checked sentence on the other.

IaaS, PaaS, SaaS: a ladder built on control

NIST’s three service models describe how much of the machine work a customer hands over, and the useful mental image is a ladder with control running up one rail. Every rung upward moves another layer into the provider’s hands.

Model	The provider’s side	Your side
IaaS, infrastructure as a service	Raw pieces: networking, compute, storage	An operating system to choose and patch, plus every task that follows from it
PaaS, platform as a service	The whole runtime: supply code and the platform executes it, hardware and base software included	Code, data, and configuration
SaaS, software as a service	An application delivered finished and maintained end to end	The content you put in: mail, meetings, records

Gmail is email as a service, Zoom is meetings as a service, Salesforce runs customer relationships as a service, and in each case the customer never touches an operating system.

Around the three core models clusters a growing acronym family, XaaS, meaning anything as a service. Its current roster includes network, database, function, security, disaster recovery, and desktop entries. Handy labels, and none disturbs the count: NIST’s three stand, the additions are packaging.

Where does serverless sit if it is not a fourth model?

To the side, as a delivery pattern. Serverless hands a provider raw code and lets the provider worry about every machine underneath: AWS Lambda, the pattern’s best-known instance, takes a function, provisions what it needs, and charges for the requests it actually serves. Idle functions cost nothing, which is what the phrase scale to zero describes. The acronym family files the pattern under function as a service, and the filing is honest: it names a way of buying compute, not a peer of the three NIST models. Listing serverless as a fourth model is the error corrected further down this page.

The pattern has a precise boundary: the provider owns provisioning, scaling, and the servers themselves, and the customer owns the code and what it does.

Public, private, community, and hybrid

The service ladder says what you rent. A second axis, the deployment models of cloud computing, says who is allowed in, and NIST lists four of them.

Model	Its audience	Its home
Public	Anyone, on published terms	The provider’s own infrastructure
Private	A single organization	Infrastructure set aside for that organization
Community	Several organizations with requirements in common	Infrastructure they share for that purpose
Hybrid	Any mixture of the above	Part dedicated, part rented

Hybrid carries the clearest use case. A workload with privacy constraints lives on the dedicated side; when traffic surges past what that side holds, the surplus runs in the public cloud, and the surge is billed only for as long as it runs. One step further sits multi-cloud, an organization deliberately split across providers, a pattern young enough that the 2011 paper does not name it.

The benefits ledger, asterisk included

The claimed benefits of cloud computing are checkable, so treat them as line items. The scalability and elasticity rows sound alike and do different jobs, and the performance row carries the asterisk.

Benefit	What it means
Provisioning speed	Capacity that once waited on a procurement cycle arrives in minutes
Money	Usage-based billing converts an owned-hardware budget into a metered one
Sizing	Allocations follow demand upward and downward, so a system built for the December peak no longer idles through June
Scalability	A customer adjusts allocations deliberately
Elasticity	The platform adjusts allocations automatically as load changes, all the way down to nothing when the load disappears
Durability and recovery	Providers run backup and disaster-recovery machinery at prices few private setups reach, and instances placed in several separate locations tolerate one of those locations going dark
Staff time	Patching, capacity planning, and hardware maintenance move onto the provider’s payroll
Performance	The asterisk: distance still governs latency, so an application placed near its audience responds faster than the same application placed far away

How do regions and availability zones contain a failure?

Geography is the tool. AWS carves the world into Regions, and its EC2 guide names closeness to specific customers among the reasons to pick one. Within a Region sit availability zones, isolated locations arranged so that a failure in one leaves the others serving; an instance group split across zones therefore survives the loss of a single zone.

The definition page compresses the global version of the offer into four quoted words, “deploy globally in minutes,” and Local Zones extend it by placing capacity close to individual metro areas. None of the placement happens automatically; the Region menu is where that choice is made.

Virtualization: the mechanism under the price

Renting by the hour pays because of one technology. Virtualization divides a physical computer into several logically independent ones, which keeps the hardware busy and the unit cost low. The supervisor program that manufactures and runs those virtual machines is the hypervisor. A virtual machine presents itself as a complete computer, with processors, memory, and disks of its own, while underneath it shares one physical box with its neighbors.

The series leans on two more terms from here on. A container isolates at the level of the operating system: the application travels together with its libraries and settings, every container on a host shares that host’s kernel, and the package weighs less than a virtual machine as a result. Cloud storage keeps data in pooled space on the provider’s machines, with availability and environmental security as the provider’s deliverables.

Why does a container weigh less than a virtual machine?

Because of where each one draws its line. A virtual machine brings its own kernel, its own operating system files, and its own slice of the hardware’s resources, since the hypervisor fences off a complete computer. A container fences off only the application and its dependencies, then borrows the kernel the host is already running. One therefore ships an operating system per workload, the other ships one per host, and the difference shows up in startup times and in how many of each fit on the same machine. Later episodes of this series return to both patterns.

Corrections the first lesson usually skips

Four mistakes recur across introductory cloud computing material, and the costliest comes first. Security is work divided between two parties, each with a fixed share. The provider’s infrastructure side covers the machinery and the buildings; the customer side varies with the service and reaches deepest at IaaS, where it includes the operating system, the firewall, the data, and who may reach either. A public deployment is not automatically the weaker of the two. The settings decide which deployment is safer, and the customer writes them.

Which half of security does a provider actually own?

AWS’s page on the subject draws the line as security of the cloud against security in the cloud. On the company’s side, its own listing runs hardware, software, networking, and facilities, together with the physical protection of the buildings. Everything above that line is the customer’s, and the page names the parts: patching the guest operating system, configuring the firewall rules, and handling data, encryption, and access permissions.

The size of the customer’s share tracks the service model, shrinking to account settings under SaaS and growing to a full operating system under IaaS. Reading the page retires the idea that security arrives with the subscription.

The second mistake is the count again: three models, with a delivery pattern promoted into a fourth, as the serverless deep dive above explains. The third is a slogan about speed. The claim that moving to the cloud shortens response times holds when the workload ends up near its users and fails otherwise; it reduces to the placement choice from the ledger.

The fourth is chronology. Cloud computing did not exist as a phrase in 1950, whatever a centenary graphic implies. Time-sharing on mainframes, starting in the 1960s, is the genuine ancestor; the network metaphor called the cloud appeared in 1994; the full term spread from a 1996 Compaq business plan; and the commercial form opened when Amazon put S3 and EC2 on the market in 2006. The series gives that road its own third episode.

How much of cloud computing predates Amazon’s 2006 launch?

Most of the lineage. Time-sharing in the 1960s ran the same bargain at mainframe scale: many remote users, one costly machine, access over wires. General Magic gave the metaphor its name in 1994, describing the Telescript world of mobile software agents in terms of the places an agent could travel to, and Compaq’s 1996 plan supplied the compound noun.

The time-sharing users of that era handed jobs to the machine’s operators and waited for output; the browser crosses the same distance today, more cheaply and more often. Amazon’s contribution was making the thing purchasable: S3 opened storage for rent, and the EC2 beta announcement is dated August 25, 2006, four decades after time-sharing put many remote users on one costly machine.

Settled, then: cloud computing is rented infrastructure reached over the Internet, 1,136 hyperscale buildings strong at the end of 2024, defined in one NIST sentence from September 2011. Three service models arrange the renting by control, four deployment models arrange the renters, the benefits arrive as a ledger with an asterisk on latency, and security splits along a line the customer half maintains. The dates close the lesson: 1960s time-sharing, a 1994 metaphor, a 1996 name, a commercial opening in 2006 with S3 and EC2.