
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.
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.
| Period | Development | What changed |
|---|---|---|
| 1960s | Interactive time-sharing | Multiple users could work with one shared computer. |
| 1960s–1970s | Mainframe virtualization | One physical system could host separate virtual machines. |
| 1969–1990s | Computer networks and the internet | Remote resources became accessible across wider networks. |
| 1990s–2000s | Hosted applications and web services | Users accessed software online; programs could call remote services. |
| 2006 | Amazon S3 and EC2 beta | Developers could request storage and virtual compute through service interfaces. |
| 2008 onward | Managed application platforms | Developers deployed applications while providers operated more of the runtime. |
| 2011 | NIST cloud definition | Cloud characteristics and service models gained a shared reference. |
| 2010s | Containers, orchestration, and serverless | Application packaging and deployment became more automated; additional operations moved to providers. |
| 2020s | Hybrid, edge, distributed, and AI infrastructure | Cloud services covered more locations, hardware types, and managed capabilities. |
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.