Today’s cloud platforms feel like a distinctly 21st-century invention, but the underlying idea — computing delivered as a shared, metered utility rather than owned equipment — is considerably older than Amazon Web Services or Google Cloud.

Before “the cloud”: time-sharing and utility computing

In the 1960s, computing was dominated by mainframes too expensive for most organizations to own outright, which led to time-sharing: multiple users accessing a single, powerful mainframe concurrently, each billed for their share of usage. Computer scientist John McCarthy is widely credited with articulating the idea that computing power might someday be organized and sold as a public utility, much like electricity — a vision that, in substance, anticipates the on-demand, metered model formalized decades later in NIST’s definition of cloud computing. The technology to deliver on that vision at internet scale, however, didn’t exist yet.

SaaS arrives early: Salesforce, 1999

Before infrastructure-level cloud services existed, Software as a Service arrived first. Salesforce launched in 1999 delivering customer relationship management software entirely over the web, rather than as software customers installed and ran on their own machines — establishing, well before the term “SaaS” was common, that a full application could be delivered as a subscription service with no local installation at all.

2006: Amazon Web Services and the modern cloud era

The event most commonly treated as the start of the modern cloud computing industry is Amazon’s launch of two infrastructure services in 2006: Amazon S3 (object storage), launched in March 2006, and Amazon EC2 (virtual compute), launched in limited beta that August. AWS describes this period directly in its account of its own origins. EC2 remained in beta for two years before reaching general availability in October 2008. What made these services significant wasn’t that renting compute was a new idea — it was that Amazon offered it with true on-demand self-service and metered, pay-as-you-go billing, at a scale and reliability that made it viable for real production workloads, not just experiments.

Google and Microsoft enter

Google followed with Google App Engine in 2008, a platform-as-a-service offering that let developers deploy application code without managing underlying servers. Microsoft entered the same year, announcing what would become Azure at its Professional Developers Conference in October 2008 under the internal code name “Project Red Dog,” reaching general availability as Windows Azure in February 2010 (later renamed Microsoft Azure). By the end of that decade, the three providers that still dominate the public cloud market today were all in the market.

2013–2015: containers and orchestration

The next major shift came from how applications were packaged and run, not from a new infrastructure provider. Docker, released in March 2013, popularized containers: a way to package an application with its dependencies into a single, portable unit that starts far faster than a virtual machine and behaves consistently across environments — a distinction covered in Serverless vs. Containers vs. VMs.

Running containers at scale, across many machines, created a need for orchestration — scheduling, scaling, and healing containerized applications automatically. Google, which had run containerized infrastructure internally for years, open-sourced Kubernetes in June 2014, drawing on that internal experience. Kubernetes reached its 1.0 release in July 2015, the same year Google donated it as the seed project for the newly formed Cloud Native Computing Foundation (CNCF), now the neutral home for Kubernetes and a wide ecosystem of related open source infrastructure projects.

Infrastructure as code and serverless, in parallel

Around the same period, two other practices took shape that are now standard. Terraform, HashiCorp’s declarative infrastructure-as-code tool, had its first release in July 2014, giving teams a provider-agnostic way to define infrastructure in version-controlled configuration — the practice covered in Infrastructure as Code: How Tools Like Terraform Actually Work. Months later, in November 2014, AWS announced AWS Lambda at its re:Invent conference, launching what’s generally regarded as the first mainstream serverless compute product and establishing Function-as-a-Service as a third compute model alongside virtual machines and containers.

What ties this history together

Each shift in this history solved a specific limitation of what came before it: on-demand self-service replaced the friction of provisioning physical hardware; containers replaced the overhead and slow startup of full virtual machines for many workloads; Kubernetes replaced ad hoc, manual container management with automated orchestration; and infrastructure as code replaced manual, undocumented provisioning with reviewable, repeatable configuration. Together, these are also the practical foundation for CI/CD as it’s practiced today — automated, frequent deployment onto infrastructure wasn’t really feasible until infrastructure itself became fast to provision, consistently packaged, and code-defined.

Key takeaway

Cloud computing’s core idea is older than any specific provider, but the industry as it exists today traces to a fairly compact sequence of events: AWS’s 2006 launch establishing on-demand infrastructure at scale, Google and Microsoft’s entry soon after, and a second wave from 2013–2015 — Docker, Kubernetes, Terraform, and AWS Lambda — that collectively produced the containerized, code-defined, automated infrastructure practices most cloud-native teams now take for granted.

This article summarizes historical and publicly documented events; specific dates and details are drawn from the linked primary sources. See our disclaimer.