The Cloud Computing Era: When the Server Disappeared

Abstract

Computing sold like electricity was proposed at MIT in 1961, built as time-sharing services in the 1960s and 1970s, and pushed aside by the personal computer in the 1980s. It came back in 2006, when Amazon began renting out storage by the gigabyte and servers by the hour. This article traces that path: the capacity-planning problem of the physical server era, the old idea of the computer utility, Amazon’s entry into the business, Google’s papers, Microsoft’s Azure, containers and serverless functions, and the failed private cloud. It also covers the price of the model. By 2025 three American companies held 63 percent of the cloud infrastructure market, and when one of their regions or identity services failed, thousands of businesses stopped at once, while European governments asked whose law applied to their data.

Buying for the Peak

Before cloud computing, every organization that ran software on the internet owned its servers. That created a problem with no clean solution.

Web traffic is not uniform. A news site receives ten times its normal traffic when a major story breaks. A retail site receives fifty times its normal load on the day after Thanksgiving. A startup might receive nothing for months, then be featured in a major publication and receive a million requests in an hour. In each case the organization had to decide how much hardware to buy, and that decision set both cost and resilience.

Buying for average load meant the site went down under peak traffic. Buying for peak load meant paying for hardware that sat idle 90% of the time. Neither answer was right.

The usual compromise of the late 1990s and early 2000s was colocation: renting rack space in a shared data center, with managed power and network connectivity, and filling it with servers you owned or leased. Companies like Exodus Communications, Rackspace, and Savvis built large facilities and rented floor space. The hardware was still yours to buy, configure, maintain, and eventually discard. Only the building was shared.

Myth: “The cloud” is some wireless, satellite-based system floating in the sky

The name is marketing; the cloud is physical. It is hundreds of large data centers filled with servers, drawing gigawatts of power and large quantities of water for cooling, and it is connected not by satellites but by a global mesh of undersea fiber-optic cables that carry over 95% of intercontinental data traffic. “The cloud is just someone else’s computer,” the saying goes, sitting in a windowless warehouse you will never see, reached over wires. See Myths and Misconceptions.

Virtualization helped. VMware, founded in 1998 by Diane Greene, Mendel Rosenblum, and others, developed software that let a single physical server run several isolated virtual machines, each with its own operating system and applications. A server that had been running one application at 10% CPU utilization could now run ten virtual machines at 10% each.

VMware’s hypervisor became standard in enterprise data centers through the 2000s. It solved the utilization problem for organizations that owned their hardware. It did not solve elasticity: when traffic doubled, you still needed more physical machines, and buying and installing them took weeks.

The Computer Utility

The idea that computing could be bought like electricity is older than the internet. At MIT’s centennial in 1961, John McCarthy said that “computing may someday be organized as a public utility just as the telephone system is a public utility.” Fernando Corbató had just shown the first time-sharing system, CTSS, which let many users at terminals share one machine, and in 1965 he and Victor Vyssotsky described Multics as a “computer utility” that “must run continuously and reliably 7 days a week, 24 hours a day in a way similar to telephone or power systems.” In 1966 the Canadian engineer Douglas Parkhill published The Challenge of the Computer Utility, which worked through the economics, regulation, and public-policy questions of such a service.

The utility was built, in commercial form. From the mid-1960s, time-sharing bureaus such as Tymshare, General Electric’s information services, and dozens of smaller firms rented terminal access to central computers by the hour, connected over telephone lines. The historians Martin Campbell-Kelly and Daniel Garcia-Swartz have shown that the business did not collapse after the computer recession of 1970 and 1971, as was long assumed, but remained a major sector of the computer services industry until the early 1980s. Then the personal computer made it obsolete.

For twenty years computing moved outward, to PCs and then to the servers each company ran for itself. The utility idea came back when the internet made the network fast and cheap enough.

Where the Word Came From

Engineers had drawn networks as clouds for decades: a lumpy outline on a diagram that meant “the part we do not need to look inside.” The earliest known use of “cloud computing” for a business is in a Compaq planning document dated 14 November 1996, “Internet Solutions Division Strategy for Cloud Computing,” written in a group around the marketing executive George Favaloro and Sean O’Sullivan of the startup NetCentric. The term entered general use on 9 August 2006, when Google’s chief executive, Eric Schmidt, described his company’s approach at an industry conference: “We call it cloud computing—they should be in a ‘cloud’ somewhere.” Amazon’s rental server service, EC2, went into beta later that month.

In September 2011 the US National Institute of Standards and Technology gave the term a working definition in Special Publication 800-145, by Peter Mell and Tim Grance: cloud computing has five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service), three service models (software, platform, and infrastructure as a service), and four deployment models (private, community, public, and hybrid). The definition is still the one used in procurement rules and textbooks.

Amazon’s Accidental Industry

Amazon had spent the early 2000s rebuilding its internal infrastructure. Its growth in the late 1990s had produced a tangle of interconnected systems that could not scale cleanly. Starting around 2002, under the direction of Jeff Bezos, Amazon re-architected the company as a set of independent services communicating through well-defined APIs. Each team owned a service; other teams consumed it through the API; no team was allowed to access another team’s data directly.

The discipline was painful. It required breaking years of accumulated complexity into clean interfaces. The result was an internal infrastructure that Amazon could operate, scale, and modify piece by piece, and the pieces (storage, compute, databases, message queues) turned out to be useful to anyone who ran software.

In 2004 Andy Jassy, then Bezos’s technical advisor, began developing the concept of selling Amazon’s infrastructure as external services. Amazon had built, at scale and under commercial pressure, the elastic, programmable infrastructure that every startup and enterprise needed and few could afford to build themselves.

On 14 March 2006 Amazon launched Amazon Simple Storage Service (S3): object storage billed by the gigabyte, accessible through an API, with no hardware to buy or manage. That August, Elastic Compute Cloud (EC2) launched in beta: virtual servers on demand, billed by the hour, available within minutes.

An EC2 instance cost $0.10 per hour. A startup could run a web service with no upfront hardware investment, scale up when traffic arrived, and scale back down when it left. The capacity-planning problem did not disappear; it became Amazon’s problem. What separated AWS from the time-sharing bureaus was less the concept than the execution: a company with the scale to make the economics work, an interface that made automation practical, and billing on a credit card, so that an individual developer could start without a procurement process.

Google’s Papers and Microsoft’s Azure

Google by the early 2000s was running one of the largest computing infrastructures in existence: thousands of cheap commodity servers, spread across data centers, answering billions of search queries. Its engineers had solved problems that the academic literature had not yet addressed, and in 2003 and 2004 Google published two papers that the rest of the industry built on.

“The Google File System” (Ghemawat, Gobioff, and Leung, SOSP 2003) described a distributed file system that stored petabytes across thousands of commodity machines and treated hardware failure as routine. “MapReduce” (Dean and Ghemawat, OSDI 2004) described a programming model for processing large datasets in parallel across a cluster, splitting work into a “map” phase that processed data in parallel and a “reduce” phase that combined the results.

Google did not release the software. It published the ideas. Within two years, engineers at Yahoo had used the papers to build Hadoop, an open-source implementation of both the file system (HDFS) and MapReduce. Hadoop became the foundation of the “big data” industry of the late 2000s and early 2010s (see The Open Source Revolution).

Google’s own cloud business arrived late. Google App Engine launched in 2008; infrastructure services comparable to AWS did not exist until 2011 and 2012. Google had the technology but little appetite for selling infrastructure to other companies, and the delay cost it years of market share.

Microsoft Azure, announced in 2008 and generally available in 2010, had a different advantage. Microsoft’s enterprise relationships, its existing data centers, and the integration of Azure with Windows Server and SQL Server gave it a path to large customers for whom AWS felt like a startup risk. Microsoft also moved its own office software into its data centers: Office 365 launched in June 2011 and ran mail, documents, and later Teams as a service, with sign-in through Azure Active Directory (see The Rise of SaaS). Azure grew into the second-largest cloud platform. The competition among the three providers is told in The Cloud Wars.

Containers

Virtualization had separated software from physical hardware. Containers separated software from the operating system.

A virtual machine runs a complete operating system: its own kernel, its own system libraries, its own processes. The isolation is thorough but expensive; each VM consumes hundreds of megabytes just to boot. A container shares the host’s kernel but isolates its own filesystem, processes, and network stack. It starts in seconds, costs megabytes of overhead instead of gigabytes, and thousands can run on one server.

Linux had supported the underlying mechanisms (cgroups and namespaces) since the late 2000s. What was missing was a usable interface. Solomon Hykes, a French-American programmer, demonstrated Docker at PyCon in March 2013. Docker packaged the Linux container primitives into a simple command-line tool and an image format that bundled an application with all its dependencies. A developer could build an image on a laptop, push it to a registry, and run an identical container in production.

By 2014 every major cloud provider supported Docker containers. Running them at scale (scheduling them across thousands of servers, handling failures, routing traffic) needed new infrastructure. Google had been running containers internally since the mid-2000s under a system called Borg, and in 2014 it released Kubernetes, an open-source orchestration system derived from Borg’s ideas. The following year Google handed it to the newly formed Cloud Native Computing Foundation (CNCF) as its founding project. An open standard that ran equally well on AWS, Azure, and Google Cloud reduced the advantage of the market leader, which suited the company in third place. By 2020 Kubernetes ran in the majority of large production deployments.

Serverless

AWS Lambda, launched in November 2014, let developers deploy individual functions without provisioning any server, virtual or otherwise. You uploaded a function; AWS ran it in response to events (an HTTP request, a file upload, a database change) and billed per invocation, in increments of milliseconds. If no one called the function, you paid nothing. If a million people called it at once, AWS scaled automatically.

The name “serverless” was controversial from the start, since there were obviously servers involved. From the developer’s point of view it was accurate: you wrote functions, defined when they ran, and stopped thinking about machines. Serverless suited event-driven workloads (image processing, API backends, scheduled jobs) and fit long-running or stateful applications poorly. It also deepened lock-in: a function written for AWS Lambda did not run unchanged on Azure Functions or Google Cloud Functions.

When the Cloud Fails

The cloud providers organized their infrastructure into regions (a metropolitan area with several data centers) and availability zones (independent data centers within a region, with separate power and networking). A customer who spread an application across zones was supposed to survive the loss of any one of them. The outages that made headlines were the ones where that design did not help, because the failure was in software shared by every zone, or by every region.

The first large one came on 21 April 2011. A network change in one availability zone of Amazon’s Northern Virginia region (US-EAST-1) was “executed incorrectly” and sent traffic onto a low-capacity backup network. Many storage nodes of the Elastic Block Store (EBS) lost contact with their mirrors, and when the network came back, they all searched for free space to copy their data to at the same moment. “The free capacity of the EBS cluster was quickly exhausted,” Amazon reported, and about 13% of the volumes in the zone were stuck. The control plane for the whole region backed up as well. Reddit, Quora, Foursquare, and Hootsuite went down or into read-only mode. API access in the affected zone came back on the evening of 23 April and the last volumes on 24 April; for 0.07% of the volumes in the zone, the data could not be restored in a consistent state.

The same region failed again in February 2017, when a mistyped command took S3 offline for more than four hours, and on 20 October 2025, when an empty DNS record made Amazon’s DynamoDB database unreachable and took down EC2, load balancers, and services from Fortnite to British banks for most of a day. In June 2025 a blank field in a quota policy crashed Google Cloud’s API gatekeeper in every region within seconds. Microsoft’s failures hit the login: on 15 March 2021 an automated job deleted a signing key that Azure Active Directory still needed, and for hours users of Teams, Exchange Online, and every application that relied on Microsoft’s sign-in could not get in. Each case is described in Famous Software Disasters.

The pattern is the one Corbató and Vyssotsky had predicted in 1965: “The more reliable computers become, the more their availability is depended upon.” A company running its own mail server could have an outage; it could not have the same outage as thousands of other companies on the same afternoon. With the cloud, a single configuration error is shared by every customer of the service. The providers answered with more regions, staged rollouts, and published post-incident reviews, which have become a genre of their own. Customers answered, when they could afford it, by spreading critical systems across several regions or several providers, which costs money and erases part of the saving that brought them to the cloud.

Dead End: The Private Cloud

The success of AWS triggered a parallel effort: if public cloud worked, could enterprises build their own, on hardware they controlled? The private cloud promised AWS-like elasticity and automation without the data sovereignty concerns, vendor lock-in, or perceived security risks of running on Amazon’s infrastructure.

OpenStack, an open-source cloud platform launched by NASA and Rackspace in 2010 and backed by a coalition of hundreds of companies, was the most prominent attempt to build a private-cloud standard. It provided the APIs, the software-defined networking, and the storage management needed to build an AWS equivalent in your own data center.

The Operational Complexity Trap

Private cloud failed because the economics did not work for most organizations. Operating one required a dedicated team of specialists to install, configure, upgrade, and maintain the platform, the same people Amazon had already hired and amortized across millions of customers. For all but the largest enterprises, the cost of that expertise exceeded the savings from not paying AWS margins.

OpenStack also suffered from fragmentation: each vendor’s distribution was slightly different, documentation was incomplete, upgrades were difficult, and the organizations deploying it often lacked the engineering depth to operate it reliably. By the late 2010s, many organizations that had built private clouds were migrating workloads to the public cloud anyway. The private cloud had solved the data sovereignty question; it had not solved the operational burden. VMware’s acquisition by Broadcom in 2023 (for $61 billion) and the price increases that followed pushed more customers out.

The hybrid cloud (some workloads on-premises, some on public cloud) became the practical compromise for large enterprises. Pure private cloud, as an alternative to public cloud, largely stopped being a credible strategy.

Concentration and Sovereignty

In the third quarter of 2025, according to Synergy Research, companies spent $107 billion on cloud infrastructure services, and three providers took 63 percent of it: Amazon 29 percent, Microsoft 20 percent, and Google 13 percent. A two-person startup could deploy worldwide infrastructure in an afternoon on hardware owned by one of the three.

The shift from buying servers (capital expenditure) to renting compute (operating expenditure) lowered the cost of starting an internet business. It also made leaving expensive. Moving off AWS was possible, but data transfer fees, proprietary services, and retraining made it far costlier than the original migration, and lock-in remained an unresolved complaint of cloud customers.

Concentration also raised the question of jurisdiction. The US CLOUD Act of 2018 lets American authorities compel US-based providers to hand over data they control, wherever it is stored. On 16 July 2020 the Court of Justice of the European Union, in the case known as Schrems II, struck down the EU-US Privacy Shield because US surveillance law did not offer Europeans equivalent protection (see Edward Snowden and the NSA). In June 2025, asked under oath by a French Senate inquiry whether he could guarantee that French citizens’ data would never be passed to US authorities without French consent, the director of public and legal affairs of Microsoft France, Anton Carniaux, answered: “No, I cannot guarantee that, but, again, it has never happened before.”

European attempts at an alternative have been slow. On 29 October 2019 the German economics minister Peter Altmaier presented GAIA-X at the Digital Summit in Dortmund, a Franco-German project for a networked European data infrastructure with founding partners such as SAP, Siemens, Deutsche Telekom, and Bosch. It was designed as a network that would connect existing European cloud providers through open standards, not as a provider of its own, and its rules on data protection and sovereignty were still to be defined when it was announced.

For the open-source software that runs inside the cloud (Linux, Kubernetes, PostgreSQL) see The Open Source Revolution. For the networking beneath it, see The Connected World and Content Delivery Networks. For the databases the cloud hosts at scale, see The Database Revolution.