2 Cloud Computing: Origins and the NIST Model

2.1 Start With What “The Cloud” Actually Replaced

Imagine a team that needs a server for a short test. It could buy a machine, wait for delivery, and set it up. Or it could request capacity from a cloud service, use it for the test, and release it when done. The cloud still runs on physical machines; the change is how people access and manage those resources.

This chapter explains where that idea came from and how NIST describes it. Later chapters use these terms to compare service and deployment choices. The IoT companion chapter applies them to placing a workload.

2.2 From Cluster to Cloud: The Computing Evolution Ladder

Cloud computing draws on several older ways to share computing. The terms below offer a useful path through the ideas, though their histories overlap rather than form a strict sequence. A cluster joins machines to work as a system. A grid shares resources across locations or groups. Utility computing offers resources as a metered service. Cloud computing adds a broad model for access to a shared pool that users can request and release quickly.

For example, two universities might use a grid to run jobs on machines at both sites. If a team can instead request capacity itself, use more as demand grows, and release it later, that illustrates cloud behavior. A bill based on use is useful evidence of metering, but a bill alone does not prove that a service has all five cloud traits.

Time-sharing let many users share a mainframe. Networks later made remote access practical, while virtual machines allowed one physical host to run isolated systems. Web software and rented virtual servers made these ideas visible to more users. These developments helped shape cloud services; none alone defines the cloud.

NIST described cloud computing in a 2009 draft and later published its definition as Special Publication 800-145. In that model, users access a shared pool of configurable resources over a network. They can obtain and release resources quickly, with little management effort or provider interaction. The pool can include servers, storage, networks, apps, and services. The definition describes a service model, not a particular vendor or product.

2.3 The Five Essential Characteristics

NIST identifies five traits that a cloud service has. They answer distinct questions: who can request resources, how users reach them, how the provider shares capacity, how quickly capacity can change, and how usage is tracked.

On-demand self-service means a user can request resources without a provider employee handling each request. For example, a team starts a server from a console at night without waiting for a ticket. Broad network access means users can reach the service over a network through standard mechanisms, using a range of clients such as laptops and phones. It does not mean that every app must run on every device.

Resource pooling means the provider serves multiple users from a shared pool, assigning resources as demand changes. Users may choose a region but generally do not choose the exact physical machine. Rapid elasticity means capacity can grow and shrink quickly, sometimes automatically. A shop might add server capacity for a sale and release it afterward. The pool can seem vast to a user, but it is not literally infinite.

Measured service means the system monitors and reports usage at a level suited to the service, such as storage or compute time. A bill can use that measurement, though the way a provider charges may vary. In the shop example, self-service starts the extra capacity, elasticity adjusts its size, and measurement records its use. Each trait describes a different part of the service.

These traits can reduce setup time and shift spending from buying hardware up front to paying for a service. Savings and reliability are possible benefits, not guarantees: they depend on design, use, and price.

2.4 Under the Hood: The NIST Three-Pillar Model and the Component Stack

NIST groups its cloud model into essential characteristics, service models, and deployment models. The five traits describe how a cloud service behaves. A service model describes what the provider supplies and what the user manages. A deployment model describes how the cloud is made available to a community of users. These are related questions, so a team can choose an answer for each.

The three service models mark different points in the stack. With infrastructure as a service (IaaS), a team rents basic resources such as virtual machines and manages more of the software on them. With platform as a service (PaaS), the provider also supplies a platform for running the team’s apps. With software as a service (SaaS), the user works with a finished app. The next chapter explores these boundaries in more detail.

The deployment models are public, private, community, and hybrid cloud. For example, public versus private is a question about who may use the cloud and how it is provisioned, not a change from SaaS to IaaS. A private cloud can be owned or operated by the organization, a third party, or both; private does not by itself tell us who owns the hardware.

A stack view helps connect the models to a real task. A browser is the client through which a user reaches a hosted app. That app runs on a platform and ultimately relies on computing, storage, and networks. These layers need not map one-to-one to service models: the model names the boundary offered to the customer. In a SaaS example such as Salesforce, the user consumes the app while the provider manages the underlying cloud infrastructure. That fact alone does not establish the deployment model.

2.5 Summary

Cloud services build on earlier ways to share computing. NIST describes a shared pool that users can access and release with little effort. Its five traits cover self-service, network access, pooling, elasticity, and measurement. Service models describe the provider and user boundary; deployment models describe who may use the cloud. A stack view shows how an app depends on lower layers, but the service model tells us which part the provider offers.

2.6 Key Takeaway

Use the cloud definition and its traits to check a service.

2.7 See Also

The next chapter explains the service models in more detail. The IoT companion applies these cloud ideas to a choice of where to run a workload.