2 Cloud Computing: Origins and the NIST Model
2.1 Start With What “The Cloud” Actually Replaced
“The cloud” is not a metaphor for a mysterious remote place. It is a specific model for renting computing resources – servers, storage, networks, and applications – with a specific set of traits (on-demand, self-service, elastic) and a specific standard body’s definition behind it. This chapter builds that definition from the ground up: where the model came from, what it formally means, and what makes it different from simply “a server owned by someone else.”
This chapter is the systems-computing foundation underneath the module’s companion book. If you have already read Cloud Computing Fundamentals for IoT, that chapter assumes you already know what IaaS, an SLA, or a deployment model are, then teaches you how to make an IoT placement decision with them. This chapter teaches what those terms are in the first place, with no IoT framing attached yet.
2.2 From Cluster to Cloud: The Computing Evolution Ladder
Cloud computing did not appear from nothing. It is the newest rung on a ladder of shared-computing models, each one adding automation and abstraction on top of the last:
Cluster Computing
Homogeneous computing nodes, connected loosely or tightly, working together as one system.
Grid Computing
Heterogeneous computing nodes distributed over a wide area, pooled to perform very large tasks.
Utility Computing
Packaged computing and storage resources made available on demand, billed like a metered utility.
Cloud Computing
A shared pool of configurable computing resources with ubiquitous, dynamic, on-demand access.
Each rung keeps what worked below it and removes a piece of manual effort. Cluster computing needed nodes an organization already owned. Grid computing spread that idea across organizations and distances. Utility computing turned the result into something you could buy by the unit. Cloud computing is what happens when utility computing gets rapid, automatic allocation and release on top – the resource pool feels effectively infinite to the person requesting it, even though real hardware sits underneath.
The timeline behind that ladder is concrete, not abstract history:
By 2009, the pattern was common enough that the U.S. National Institute of Standards and Technology (NIST) wrote it down as a formal definition – not to invent cloud computing, but to stop every vendor from using the word to mean something different:
NIST’s definition (P. Mell & T. Grance, “The NIST Definition of Cloud Computing,” version 15, 2009): “Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., network infrastructures, servers, storage, applications, etc.).”
Read that definition slowly and four separate claims are packed into it: the access is convenient and on-demand (you do not file a purchase order and wait); the pool is shared (many tenants draw from the same underlying hardware); the resources are configurable (you shape them to your workload, you do not take them as-is); and it is explicitly a model, not one specific product. NIST also frames it as a step on from utility computing: a high-level generalization (abstraction) of computation and storage that can be rapidly allocated and released with low management effort.
2.3 The Five Essential Characteristics
NIST’s definition names three things every cloud service must have alongside it: essential characteristics, service models, and deployment models. This section works through the first of those three – the five traits that separate a genuine cloud service from “a server someone else administers for you.” A hosting arrangement that is missing any one of these five is not a cloud service in the NIST sense, whatever marketing calls it.
On-Demand Self-Service
A consumer can provision server time and storage automatically, without requiring a human interaction with the provider. If getting a new virtual machine means emailing someone and waiting a day, this characteristic is missing.
Broad Network Access
Capabilities are available over the network through standard mechanisms, reachable from heterogeneous thin or thick clients – phones, laptops, and tablets alike, not one proprietary client application.
Resource Pooling
The provider’s resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. The consumer generally has no control over the exact physical location of the resource.
Rapid Elasticity
Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward with demand. To the consumer, the capabilities available often appear unlimited and purchasable in any quantity at any time.
Measured Service
Cloud systems automatically control and optimize resource use by metering at a level of abstraction appropriate to the service type (storage, processing, bandwidth, active accounts). Usage is monitored, controlled, and reported, giving transparency for both provider and consumer.
Alongside these five, the source material lists a set of general characteristics that tend to follow once the five essential ones are in place: improved agility in resource provisioning, ubiquity (independent of device or location), the multitenancy already named above, dynamic load balancing, high reliability and scalability, and lower cost and maintenance burden than owning the equivalent hardware outright.
Those traits translate into concrete business advantages, which is why the model spread as fast as it did: nearly zero upfront infrastructure investment, real-time infrastructure availability instead of a procurement cycle, more efficient resource utilization through pooling, usage-based costing instead of fixed capital spend, and a shorter time to market for a new product.
2.4 Under the Hood: The NIST Three-Pillar Model and the Component Stack
NIST’s visual model organizes the whole definition into three pillars, and this module’s remaining chapters are, structurally, just an expansion of one pillar at a time:
Essential Characteristics
Broad network access, rapid elasticity, measured service, on-demand self-service, resource pooling – covered above. These five apply to every cloud service, regardless of model.
Service Models
Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) – what layer of the stack the provider hands you versus what you still build yourself. The next chapter in this module builds this pillar in full.
Deployment Models
Public, private, hybrid, and community cloud – who the resource pool is shared with and who owns the infrastructure. This module returns to this pillar in a later chapter.
A second, complementary view of the same system is the layered component stack. Reading it bottom to top: infrastructure (virtualization, IaaS, raw compute such as EC2) supports storage (databases, Data-Storage-as-a-Service), which supports the platform layer (application and web hosting via PaaS), which supports applications (web apps, SaaS), which supports services (packaged products such as identity, mapping, or search), which finally reaches clients (thick, thin, or mobile end-user devices). Each layer is a service boundary: what one layer needs, it requests from the layer below rather than building itself.
A second version of that same stack, drawn as service models directly, shows Clients on top (split into a user interface and a machine interface), then Application (components and services), then Platform (compute, network, storage), then Infrastructure, then Servers at the base. This is the same idea as the layered component stack above, just relabeled around SaaS/PaaS/IaaS instead of the more granular six-layer breakdown – the next chapter in this module works through exactly what “who manages what” means at each of those boundaries.
The chapter closes where the next one starts: Software-as-a-Service is the layer end users touch most directly. It is the facility to execute the provider’s application at the user’s end, delivered through a browser or app, where the end user does not control the underlying cloud infrastructure at all. Early, recognizable SaaS products – Google Apps, Salesforce, Learn.com – are the concrete anchor for what “the top of the stack” looks like before the next chapter opens up IaaS and PaaS underneath it.
2.5 Summary
Cloud computing is the newest rung on a cluster-grid-utility-cloud evolution ladder, formalized by NIST in 2009 as convenient, on-demand network access to a shared, configurable resource pool. That definition rests on five essential characteristics – on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service – that apply across every service model. NIST’s own visual model organizes the rest of the topic into three pillars: essential characteristics (this chapter), service models (the next chapter), and deployment models (a later chapter). The same system can also be read as a layered component stack running from infrastructure up through storage, platform, applications, services, to clients.
2.6 Key Takeaway
“The cloud” is not a synonym for someone else’s server. It is a specific, five-trait model with a formal 2009 definition behind it, and every later cloud-computing topic in this module is an expansion of one of NIST’s three pillars: characteristics, service models, or deployment models.
2.7 See Also
Service Models: IaaS, PaaS, and SaaS
The next chapter in this module: builds the full IaaS/PaaS/SaaS taxonomy this chapter previewed.
Cloud Computing Fundamentals for IoT
The applied companion chapter: takes this chapter’s definitions and uses them to make an IoT workload-placement decision.