← Blog
A vintage computer terminal with a mint cloud on its screen, drawn in thin charcoal lines against a pale peach background.
Published on
2024-07-10

The history and development of cloud computing: a clear timeline

The development of cloud computing spans several decades. Time-sharing made expensive computers accessible to multiple users; virtualization let different systems share hardware; networks connected people to remote resources. Web applications, service interfaces, and automation later made software, storage, and computing capacity available on demand.

There is no single cloud computing inventor or release date. The commercial services that emerged in the late 1990s and 2000s combined ideas developed by researchers, engineers, software companies, and infrastructure providers. Understanding those contributions gives a more useful history than choosing one company as the starting point.

Cloud computing history at a glance

These milestones show what changed for users at each stage. The periods overlap: a new approach could expand the available choices while older systems continued operating.

PeriodDevelopmentWhat changed
1960sInteractive time-sharingMultiple users could work with one shared computer.
1960s–1970sMainframe virtualizationOne physical system could host separate virtual machines.
1969–1990sComputer networks and the internetRemote resources became accessible across wider networks.
1990s–2000sHosted applications and web servicesUsers accessed software online; programs could call remote services.
2006Amazon S3 and EC2 betaDevelopers could request storage and virtual compute through service interfaces.
2008 onwardManaged application platformsDevelopers deployed applications while providers operated more of the runtime.
2011NIST cloud definitionCloud characteristics and service models gained a shared reference.
2010sContainers, orchestration, and serverlessApplication packaging and deployment became more automated; additional operations moved to providers.
2020sHybrid, edge, distributed, and AI infrastructureCloud services covered more locations, hardware types, and managed capabilities.

1960s: time-sharing makes interactive computing a shared service

Early mainframe computers often processed jobs in batches. A user submitted a program and its data, then waited for the machine to complete the work. Access to an expensive computer was organized around a queue, with limited opportunity to adjust a program while it ran.

Time-sharing divided processor time among users quickly enough for them to work interactively. MIT's Compatible Time-Sharing System, or CTSS, was demonstrated in 1961. Its later operation included remote access through terminals and dial-up connections. Project MAC expanded work on interactive computing during the 1960s.

Planning for Multics began in 1964. In their account of the project's first seven years, its developers described a computer utility with convenient remote access, continuous operation, and capacity that could grow. Those goals show how early researchers were already thinking about computing as an ongoing service.

Time-sharing established shared, interactive access to computing capacity. Modern cloud services added a different combination of resource pooling, automated provisioning, elasticity, and standardized interfaces. Treating CTSS as a predecessor of modern cloud computing preserves that distinction without diminishing its contribution.

1960s–1970s: virtualization separates a machine from its hardware

Virtualization lets one physical computer support multiple virtual machines, each with its own operating environment. A control layer allocates access to processor, memory, and other resources. Users can work with a logical machine without requiring a separate physical hardware for every workload.

IBM's virtual-machine work included CP-40 and CP-67 during the 1960s. The company announced VM/370 on August 2, 1972, bringing these ideas into an official product for the System/370.

This separation became an important foundation for cloud infrastructure. A provider could allocate virtual machines from a pool of hardware, while customers installed software in their own environments. The physical capacity still had to exist, and isolation depended on the implementation.

A virtualized data center does not automatically provide cloud services. Self-service access, provisioning, usage measurement, and resource management require additional systems. Cloud providers can also deliver bare-metal servers alongside virtual machines.

1969–1990s: networking and distributed computing connect remote resources

Shared computing became more useful as people could reach it from farther away. DARPA records the first computer-to-computer signal on ARPANET in October 1969. The initial four-node network was an important step in the development of the internet; its transition to TCP/IP in 1983 helped connect different networks.

Commercial internet access and the web later expanded the audience for remote applications. Browsers offered a common way to interact with services, while web interfaces allowed software on different systems to communicate. Organizations could deliver applications to customers without installing the full application on every device.

Networking also supported distributed computing, where components coordinate across multiple machines. That architectural idea overlaps with cloud computing, but the two terms describe different things. Our guide to how distributed processing works explains how machines divide and coordinate work.

Clusters and grid computing develop alongside the web

Networks also let organizations combine computing resources for large jobs. Clusters coordinated machines as a group, while grid computing connected resources across wider organizational boundaries. The Globus Toolkit supported grid and high-performance computing infrastructure, including research environments that institutions operated themselves.

Grid computing and cloud services overlap in sharing resources, but access, ownership, and operational arrangements can differ. Research grids were one strand of the broader development of networked computing. They did not simply disappear when commercial cloud platforms became available.

1990s–2000s: hosted software makes online services familiar

Web hosting and remotely operated business applications helped establish the commercial case for accessing software as a service. Customers could use an application online while its provider ran the servers and delivered updates. Different services used subscriptions, usage charges, or other pricing arrangements.

Salesforce is a useful milestone in this development. According to its company history, it incorporated in March 1999 and officially launched in February 2000. Its web-delivered customer relationship management software helped popularize software as a service, or SaaS. The founding date should not be confused with the public launch, or treated as the invention of all hosted software.

The historical change concerned both delivery and responsibility. Users increasingly expected to open an application and work with it, while the provider maintained its operating environment. Infrastructure services would extend a related approach to developers who needed computing resources for their own software.

2006: data storage and compute become cloud services

Amazon introduced Simple Storage Service, or S3, in March 2006. It provided an interface for storing and retrieving data without purchasing the underlying storage hardware. In August, Amazon opened EC2 for limited beta testing. Elastic Compute Cloud gave developers access to virtualized computing resources.

These public cloud services were major milestones for infrastructure as a service, or IaaS. Developers could request resources through service interfaces and build provisioning into software workflows. The provider handled the physical infrastructure; customers retained control of their operating systems and applications.

For example, a development team could create a test environment, use it for a release, and remove it afterward. Doing that reliably still required configuration and automation, but it no longer depended on buying a dedicated server for each environment.

The importance of 2006 lies in making programmable infrastructure commercially accessible. Time-sharing, virtualization, networking, and hosted applications already existed. AWS combined such ideas into services that helped establish modern public cloud computing.

2008 onward: platform as a service expands cloud computing services

Google App Engine launched in 2008 as a managed application platform. Developers deployed applications into a supported environment, while Google operated the runtime and associated services.

This illustrates platform as a service, or PaaS. With IaaS, a team can manage a virtual machine and its operating system. With PaaS, it deploys code within the platform's supported languages, libraries, and execution model. The provider takes on more operational work, and the developer accepts the platform's constraints.

Microsoft added another major platform when Windows Azure became generally available in February 2010. Its entry illustrates how cloud service providers were developing different platforms in parallel, rather than following one universal sequence of product launches.

IaaS, PaaS, and SaaS developed alongside one another. They serve different needs, so the growth of managed platforms did not make infrastructure services obsolete. A business might use SaaS for collaboration, a managed platform for an application, and virtual machines for software needing more control.

2011: NIST defines cloud computing models and characteristics

In September 2011, the US National Institute of Standards and Technology published Special Publication 800-145. Its definition of cloud computing gave organizations a shared way to distinguish cloud computing from generic remote hosting.

NIST identified five essential characteristics:

  • On-demand self-service: users obtain capabilities without a provider employee processing every request.
  • Broad network access: standard network mechanisms make services accessible from different kinds of devices.
  • Resource pooling: a pool of resources serves multiple consumers and can be reassigned.
  • Rapid elasticity: capacity can expand and contract with demand, sometimes automatically.
  • Measured service: resource use is monitored, controlled, and reported.

The publication also described the IaaS, PaaS, and SaaS cloud computing service models, plus private, community, public, and hybrid deployment models. It documented an established set of ideas rather than launching a new service.

This distinction remains useful: a remote server alone does not demonstrate all five characteristics. Equally, a private cloud can provide them without offering services over the public internet. Metering supports visibility and charging, but cloud services need not all use the same billing unit or subscription structure.

2010s: containers and orchestration change application deployment

Containers package applications and their dependencies into units that can run in compatible environments. They generally share the host operating-system kernel, whereas a virtual machine provides a separate guest operating system.

Containers predated Docker, but Docker made their build-and-run workflow more accessible to developers. Its first public demonstration took place in March 2013. Packaging software into an image helped teams move the same application between development, testing, and production, subject to compatibility and configuration.

Running many containers created a coordination problem: deciding where they should run, connecting services, adjusting capacity, and replacing failed instances. Kubernetes became a prominent tool for this work. The project's first commit was in June 2014, with version 1.0 released in July 2015.

Containers and virtual machines continue to coexist. A team may run containers on virtual machines, on physical servers, or through a managed service. Orchestration automates specified operations; application design still determines whether scaling and recovery behave as intended.

2010s: serverless computing and managed services shift responsibilities

Cloud providers also expanded services that hide more infrastructure management from application teams. Managed databases, message queues, storage, and analytics offer capabilities without requiring customers to operate every component themselves.

AWS introduced Lambda in preview in November 2014. Developers supplied functions that ran in response to events, while the service managed the compute resources. This became a prominent example of serverless computing.

Servers remain part of serverless services. What changes is the customer's responsibility for provisioning and maintaining them. Teams still manage application logic, permissions, data, dependencies, and the consequences of service limits. Functions are one form of serverless delivery; the label is also used for other managed capabilities.

There is no universal ladder on which every workload moves from IaaS to PaaS to serverless. Greater management by a provider can reduce operational tasks, while introducing constraints on execution, configuration, or portability. The development of cloud computing has expanded those choices.

2020s: edge computing and AI diversify cloud infrastructure

Modern cloud infrastructure combines several deployment approaches. Public and private clouds can connect through a hybrid cloud model, while multicloud describes the use of more than one provider. Edge computing places selected processing closer to devices or users. Distributed infrastructure coordinates resources across locations.

These arrangements change where work happens and how systems are managed. They do not remove the need for physical processors, storage, networks, and power. Our guide to where cloud data is stored explains that physical layer.

Artificial intelligence has added demand for specialized accelerators and managed model services. A team can obtain GPU capacity to run its own software or call a managed inference service through an API. Those choices continue the familiar distinction between accessing infrastructure and consuming a higher-level capability. AWS's service history, for example, records the expansion into managed machine learning, dedicated AI chips, and model services.

No single physical architecture defines every cloud service. Centralized facilities, regional resources, and edge locations can serve different workloads. Their coexistence explains the current diversity more accurately than a prediction that one approach must replace the others.

Questions about the origins and evolution of cloud computing

Who invented cloud computing?

No single person or company invented the whole model. Time-sharing researchers, virtualization engineers, networking teams, hosted-software companies, infrastructure providers, and standards bodies contributed different parts. Their work accumulated over decades.

When did cloud computing start?

Its technical roots include time-sharing in the 1960s and mainframe virtualization. Recognizable commercial online software and infrastructure services emerged later. Amazon's S3 and EC2 launches in 2006 are major infrastructure milestones, while the 2011 NIST publication provides a widely used definition. Each date answers a different historical question.

What was the first cloud service?

There is no useful universal answer without specifying the kind of service. Shared remote computing, hosted applications, and programmable infrastructure have different histories. Identifying a documented launch is more precise than declaring one product the first cloud of every kind.

Is the origin of the name the same as the origin of the technology?

No. Naming a service model and developing its underlying technologies are separate events. Claims about who coined “cloud computing” require their own historical evidence and cannot establish who invented the full model. This timeline follows documented systems, services, and standards.

What changed most as cloud computing developed?

As cloud computing evolved, users gained more ways to access shared computing resources, automate provisioning, and assign operational tasks to a provider. Earlier techniques remain in use underneath newer services. When assessing a cloud service today, the useful questions are which resources it provides, where they run, and which responsibilities remain with the customer.

Your next workload belongs on Hivenet.

Pick one AI, compute, or storage workload and see the difference for yourself. Spin it up in minutes, or let our team map your fastest path to production.