Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Cloud computing grew from decades of shared-computing, virtualization and networking ideas rather than appearing as a single invention. Time-sharing demonstrated how many people could use one powerful computer, virtualization made separate environments practical on shared hardware, networking connected distributed resources, and on-demand commercial services made the model broadly accessible.

What is cloud computing?

Cloud computing is a way to obtain computing resources over a network when they are needed, without an organization having to own and operate every underlying machine. That description is useful, but it is broader than simply placing a server in a remote data center. The defining question is how resources are pooled, requested, scaled and released.

The National Institute of Standards and Technology (NIST) defines cloud computing as convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with little management effort or provider interaction. Its formal definition appears in NIST Special Publication 800-145, published in September 2011. NIST computer scientist Peter Mell said the definition gives agencies and companies a way to judge how closely an implementation matches cloud characteristics and models, as quoted in NIST’s publication account.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

NIST’s framework identifies five essential characteristics:

  • On-demand self-service: a customer can provision capabilities such as storage or processing without a person at the provider having to configure each request manually.
  • Broad network access: services are reachable over networks using standard mechanisms and from a range of client devices.
  • Resource pooling: a provider serves multiple customers from a shared pool of physical and virtual resources, allocating capacity dynamically.
  • Rapid elasticity: capacity can expand or contract quickly enough to appear, from the customer’s perspective, almost unlimited when compared with a fixed local installation.
  • Measured service: usage is monitored, controlled and reported, supporting transparency and consumption-based charging.

A remote server that is manually configured for one customer may be useful hosting, but it does not automatically provide all five characteristics. Cloud computing is therefore an operating and service model, not merely a location.

How did cloud computing develop?

Early 1960s: utility computing and virtual machines

The earliest roots are shared-computing proposals from the 1960s. In testimony on the subject, NIST traces utility-computing ideas and mainframe techniques that made one computer appear to be multiple virtual computers to that period. The utility analogy imagined computing consumed like electricity: users would obtain capacity when required instead of buying an entire machine.

The hardware and networks of the time limited that vision. NIST identifies performance, cost and inadequate networking as barriers. The concepts existed before the infrastructure could deliver them economically or with acceptable responsiveness. Cita Furlani, then director of NIST’s Information Technology Laboratory, summarized the historical relationship in congressional testimony: “Although the power of modern cloud computing systems is new, the ideas behind cloud computing reach back through decades.” The statement is recorded in NIST testimony.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

1964 and the 1960s–1970s: time-sharing

IBM’s history of time-sharing describes the System/360, introduced in 1964, as powerful enough to support a major expansion of shared access. Instead of one person running a batch job and waiting, many users could work through remote terminals connected to a central computer. The system divided processor time and other resources among active sessions, giving each user the impression of a responsive computer.

Time-sharing became popular during the 1960s and 1970s. It established an important cloud-like principle: the user consumes computing capability without directly possessing the machine that supplies it. It was not modern cloud computing, however. Capacity was usually tied to a particular institution and mainframe, provisioning was not the automated, elastic process defined by NIST, and networking was far less ubiquitous.

1970s: virtualization on mainframes

IBM’s account also describes the VM operating system on System/370 in the 1970s. VM could let multiple virtual systems run on one physical node, isolating workloads while sharing hardware. This is an antecedent to modern server virtualization: software creates logical machines that are distinct from the underlying physical host.

Virtualization improved utilization and made it easier to move or reorganize workloads without assigning one physical computer to every application. Modern hypervisors, virtual networks and virtual storage extend the same general idea with far greater automation and scale. The historical connection should be stated carefully: a mainframe virtual machine is not identical to a contemporary public-cloud instance, but it supplied a crucial abstraction for later infrastructure services.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Early 1980s: the personal-computer interruption

IBM says time-sharing waned as microcomputers became more powerful and less expensive in the early 1980s. Local computing reduced the need for many users to share a distant central system for everyday tasks. This was not the end of shared computing; it was a change in where the value was greatest. Central systems continued to serve organizations, while personal computers introduced a long period in which owning a machine often seemed simpler than renting interactive access.

1990s: the Internet and grid computing

By the 1990s, the Internet provided a much broader network over which computers could cooperate. NIST describes grid computing as a bridge in which machines worked together across a network. Grid projects commonly coordinated distributed capacity for scientific, engineering or institutional workloads rather than presenting a single commercial catalog of self-service resources, but they demonstrated that useful computation could be assembled from geographically separated systems.

This period also supplied practical lessons about identity, scheduling, data movement, reliability and network dependence. Those concerns remain visible in cloud services today. The Internet did not by itself create cloud computing; it made large-scale remote access and coordination feasible enough for later service models.

2006: on-demand storage and compute become commercial milestones

Amazon Web Services identifies the launch of S3 storage in 2006 and EC2 compute a few months later as major steps in its own history. S3 offered remotely accessible storage, while EC2 offered compute capacity that customers could request rather than purchase as a fixed server. Amazon’s retrospective describes the March 2006 launch in terms of on-demand, pay-as-you-go access.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

These launches made the utility idea concrete for a much larger developer audience: a small team could obtain storage and processing through an interface, use them for as long as needed and scale without building a data center first. The relevant historical sources are AWS’s origins account and Amazon’s retrospective. They establish important commercial milestones, not proof that one provider invented every cloud concept or was the first commercial cloud service. The sources reviewed do not establish a definitive first service or an exact coinage date for the phrase “cloud computing.”

2011: NIST supplies a shared vocabulary

NIST published the final version of SP 800-145 in September 2011 after 15 drafts. The document’s importance is organizational as much as technical: it gives buyers, engineers and public agencies a common way to discuss what is being delivered and how it is deployed. The final framework separates five characteristics, three service models and four deployment models instead of treating every remote service as equivalent.

Why virtualization and networking made the modern model practical

Cloud computing depends on several layers reinforcing one another:

  • Virtualization abstracts hardware. A provider can divide a physical server into multiple isolated virtual machines, assign resources programmatically and move workloads as capacity changes.
  • High-speed networks make remote use tolerable. Storage, applications and management interfaces can be reached from many locations, while internal provider networks connect servers, storage systems and facilities.
  • Automation turns capacity into a service. APIs, orchestration and monitoring allow provisioning and release to happen in minutes or seconds rather than through a manual purchasing and installation cycle.
  • Large pools improve statistical sharing. Different customers tend to use capacity at different times. A pooled environment can therefore serve more total demand than a set of permanently dedicated machines with the same nominal peak capacity.

These advantages introduce dependencies as well. Availability relies on networks and provider operations; confidentiality and integrity require sound access controls and data handling; and moving workloads between environments can be difficult if interfaces or data formats are proprietary. NIST’s earlier testimony highlights confidentiality, integrity, availability, interoperability and portability as continuing considerations, not as a quantitative scorecard for every provider.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What are IaaS, PaaS, and SaaS?

Service models describe the layer a provider supplies and the work left to the customer. They are different from deployment models, which describe the overall arrangement of the cloud. Microsoft explains the practical distinction in its service-model guide, while NIST provides the formal categories.

Service model Provider generally supplies Customer generally manages Control, flexibility and simplicity
Infrastructure as a Service (IaaS) Virtual machines or other compute, storage and networking foundations Operating systems, applications, data, configurations and often security settings above the infrastructure layer Most infrastructure control and flexibility of the three, with more operational responsibility
Platform as a Service (PaaS) A managed operating environment, runtime, middleware and related development services Application code and data, plus the settings exposed by the platform Less infrastructure administration and faster development, but less control over the underlying platform
Software as a Service (SaaS) A complete application delivered over a network User accounts, permissions, content and organization-specific settings Greatest operational simplicity and least control over the underlying stack

The models are not a ladder in which an organization must choose one forever. A business can use SaaS for office work, PaaS for a custom application and IaaS for a specialized workload at the same time. Nor does IaaS mean public cloud by definition: infrastructure can be delivered in private, public, community or hybrid arrangements.

How deployment models differ

NIST’s four deployment models answer a separate question: who shares the environment, who controls it and where its boundaries lie.

Deployment model Meaning Typical reason to choose it
Private cloud Cloud infrastructure is provisioned for exclusive use by one organization, though it may be owned, managed or located by that organization or a third party. More direct control over policy, data placement or customization.
Community cloud Infrastructure is shared by a specific community of organizations with common concerns, such as mission, security or compliance requirements. Shared costs and capabilities among organizations with aligned needs.
Public cloud Infrastructure is available for open use by the general public and operated by a provider or other organization. Broad access to pooled capacity and provider-operated services.
Hybrid cloud Two or more distinct cloud infrastructures remain separate but are connected so data or applications can move between them. Combining environments for resilience, policy, capacity or workload placement.

A service model and a deployment model can therefore be combined in many ways. For example, a private PaaS and a public IaaS are different choices along two different axes.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What changed for organizations?

The historical shift was not simply from local servers to rented servers. Cloud services changed the timing and granularity of decisions. Instead of forecasting hardware demand years ahead, a team can request a smaller amount of capacity, observe usage and expand when required. Measured service also makes consumption visible, which can improve accountability but can produce unexpected bills when resources are left running or data transfers are overlooked.

Responsibility moves rather than disappears. A provider may operate buildings, physical hosts and core services, while the customer remains responsible for identities, permissions, application code, data classification and configuration choices. The exact boundary varies by service model. Portability can also be limited: an application that depends heavily on one provider’s interfaces may be difficult or expensive to move, even if the underlying virtual machines appear portable.

Edge computing: bringing some work closer to the source

Cloud architecture does not require every operation to travel to a distant centralized facility. Microsoft Research defines edge computing as placing computing resources near the sources where information is generated, reducing latency and the bandwidth use commonly associated with sending everything to a central cloud. Its project history says the idea was discussed in a Microsoft Research brainstorming session with researchers and industry colleagues on October 29, 2008. That date documents the history of that research effort, not a universal invention date for edge computing.

Edge and cloud can complement each other. A sensor, vehicle or industrial controller may need a rapid local response or may operate intermittently connected, so an edge device can filter data or make an immediate decision. The cloud can still provide centralized storage, fleet management, model training, long-term analysis and coordination. The design question is where each task best balances latency, bandwidth, resilience, privacy and operational cost.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

AI, interoperability and the next phase

Amazon’s 2026 retrospective points to AI services, connections across multiple environments and interoperability as continuing directions in cloud computing. Those are observations from Amazon’s own account, not settled predictions for the entire industry. AI workloads can require substantial accelerators, fast data pipelines and elastic capacity, while also creating pressure to keep sensitive or latency-critical processing closer to users and devices.

Interoperability is consequently more than a marketing term. It can involve compatible identity systems, data formats, networking, application interfaces and operational tools across public cloud, private infrastructure and edge locations. Greater compatibility may reduce switching barriers, but it can also add engineering work and constrain the use of specialized services.

A reasonable synthesis of these trends is that future architectures will negotiate among scale, latency, portability, interoperability, security and cost. No single direction is guaranteed: centralized cloud services, local edge processing and specialized AI hardware are likely to coexist, with placement determined by the workload rather than by a universal replacement cycle.

A concise way to remember the history

  1. Shared access came first: time-sharing let many people use one central computer through terminals.
  2. Virtualization separated logical machines from physical hardware: mainframe virtual systems established an important abstraction.
  3. Networks expanded the pool: the Internet and grid computing connected distributed resources.
  4. Automation commercialized the model: on-demand storage and compute services in 2006 made consumption-based infrastructure practical for a broad developer market.
  5. NIST clarified the vocabulary: the 2011 definition distinguishes characteristics, service layers and deployment arrangements.
  6. New workloads change placement: edge processing, AI and interoperability extend the same resource-sharing story while adding new trade-offs.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.