Blog · Review Essay · Modified August 12, 2026 · Last reviewed August 12, 2026

A Prehistory of the Cloud and the Infrastructure That Pretends to Disappear

Tung-Hui Hu's A Prehistory of the Cloud is not simply a history of remote servers. It is a genealogy of how older routes, institutions, security practices, and ideas of the user were repackaged as a weightless service. Its AI-era value is direct: a model answer can feel local and immediate while depending on remote energy, labor, identity, policy, logging, and update authority.

Cloud has two meanings that should not be collapsed. NIST defines a technical service model built around on-demand access to pooled, configurable resources. This review uses cloud infrastructure for the wider institutional arrangement that delivers those resources: facilities, networks, contracts, jurisdictions, credentials, telemetry, billing, security, and the provider's power to change the service. The first definition explains delivery; the second locates control.

The governance test is therefore evidentiary. Can an institution locate its data and logs, name who can alter or access them, reconstruct what the service did, revoke its credentials, export and restore its records, and continue operating if the provider changes or fails? If not, convenience has become an unrecorded transfer of institutional capacity.

The Book

MIT Press published A Prehistory of the Cloud in hardcover in 2015 and paperback in 2016; both editions are listed at 240 pages. The publisher describes a path through railroad tracks, sewer lines, television circuits, time-sharing, data storage, and Cold War bunkers later reused as data centers. That list is not background color. It supports the book's central refusal of digital exceptionalism: what looks unprecedented at the interface often inherits routes, buildings, institutions, and political habits from earlier systems.

Prehistory here does not mean a neutral chronology of what came before commercial cloud services. It means an archaeology of conditions that the finished product teaches users to forget. Steven Shaviro usefully describes the argument as moving from network infrastructure through virtualization and storage to data mining and power. Across those layers, Hu treats the cloud at once as a technical arrangement, a cultural image, a security fantasy, and a way of producing the person called a user.

Hu's experience as a former network engineer, alongside his work as a poet and media scholar, helps the book move between equipment and metaphor without pretending they are the same thing. NIST's engineering definition remains useful: five essential characteristics, three service models, and four deployment models organize how cloud resources are delivered. Hu asks the different question that definition is not designed to answer: which histories, jurisdictions, labor relations, and forms of authority are carried inside the delivery model?

The book belongs beside The Stack, The Metainterface, Cloud Empires, The Costs of Connection, and the data-center essay. Together they show that an interface is also an allocation of visibility: users receive a simplified service while providers and infrastructure owners retain broader views of routing, capacity, policy, and failure.

Vanishing Infrastructure

The cloud's first operation is aesthetic. It presents computation as atmosphere: available, elastic, and without a place. Hu repeatedly pulls that image back toward tracks, cables, facilities, cooling, storage media, diagrams, checkpoints, and maintenance. The point is not the easy slogan that the cloud is really someone else's computer. It is that a large administrative system has been compressed into an object simple enough to buy, click, and forget.

The consequential form of invisibility is asymmetric legibility. At each layer, operational detail is concentrated upstream while the customer receives a narrower control surface. The facility becomes a region label; the region becomes an endpoint; the endpoint becomes an app; the contract becomes an account; the account becomes the feeling that a file, model, assistant, or memory is simply mine. Each abstraction can be technically useful while the chain as a whole makes responsibility difficult to trace.

That is why the metaphor has governance effects. A failure can be recast as downtime instead of loss of public capacity. A change in retention can appear as a settings update rather than a records decision. A new identity requirement can look like account security while excluding people from a service. A transmission upgrade can disappear into the price of inference. The interface does not merely conceal things; it changes the category in which a problem can be raised.

Virtualization therefore does not make infrastructure unreal. It separates the customer's view from the operator's control. NIST's access-control guidance confirms the practical side of this distinction: IaaS, PaaS, and SaaS expose different components and require different access decisions. Hu supplies the political consequence. When the party affected by a system cannot see or alter the layer where a decision is made, technical abstraction becomes an accountability boundary.

The User as Political Form

The book also sharpens the word user. A user is not merely a person with access. It is the form of person a system can authenticate, meter, profile, support, suspend, and assign responsibility to. Kevin Driscoll's review identifies the political loss: people meet shared infrastructure as isolated account holders rather than as a public with a common claim on how that infrastructure operates.

The account is both useful and narrowing. It secures a session, stores preferences, attributes cost, and enables recovery. But it also routes disagreement into the vocabulary of service: appeal becomes support, exclusion becomes account status, institutional policy becomes terms of use, and a common outage becomes many private tickets. The person may still be a student, worker, patient, resident, or citizen with rights, even when the interface recognizes only a customer or administrator.

Cloud interaction also creates a feedback loop. A person uploads, prompts, tags, searches, saves, corrects, and shares. Depending on the service and its terms, those acts can become telemetry, security evidence, product metrics, recommendation inputs, or training material. The resulting system updates what the person sees and can do, producing the next round of behavior. The political question is who can inspect, contest, or interrupt that loop when the dashboard shows only personalization.

This makes the public/private distinction operational rather than rhetorical. A school cannot discharge due-process duties by pointing to an account menu. A city cannot preserve a public record merely because a vendor retains a log. A clinic cannot establish confidentiality by selecting a region label. The interface may be individualized, but the obligations surrounding it remain institutional.

Current Context

As of August 12, 2026, the material scale of Hu's argument is clearer than it was at publication. The International Energy Agency's April 2026 Key Questions on Energy and AI put global data-center electricity consumption at about 485 terawatt-hours in 2025 and projected about 950 terawatt-hours in 2030, roughly 3% of global electricity demand. It also estimated that electricity use by AI-focused data centers rose 50% in 2025 and would triple between 2025 and 2030.

Those are system-level estimates and projections, not measurements of a particular prompt, model, or facility. Lawrence Berkeley National Laboratory's June 2026 U.S. update estimated 192 terawatt-hours in 2024, 4.7% of national electricity use. Its 2030 reference case is 649 terawatt-hours, or 11.8% of forecast U.S. electricity, with a compounded uncertainty range of 521 to 843 terawatt-hours, or 9.5% to 15.3%. That bottom-up U.S. model and the IEA's global model use different scopes and assumptions, so their projections should not be added or treated as interchangeable. Their wide ranges reinforce the planning problem: utilities can build long-lived capacity around demand forecasts that are faster-moving and more speculative than grid infrastructure.

The U.S. regulatory record now separates tariffs from reliability standards. On June 18, FERC issued show-cause orders requiring the six regional grid operators under its jurisdiction and their transmission owners to justify existing large-load rules or propose tariff changes within 60 days. Those orders opened proceedings around study processes, cost shifting, co-location, flexible service, and generation near large loads; they were not themselves final tariffs or local siting approvals.

On July 16, FERC separately directed NERC to develop new or modified Reliability Standards for computational-load integration and revisions to its Rules of Procedure, including registration criteria for computational-load entities, by December 31, 2026. Until that work is completed and acted on, NERC's May guideline remains guidance rather than an enforceable Reliability Standard. The distinction matters: a planning recommendation, a proposed standard, an approved standard, a tariff, a retail rate, and a local permit govern different parts of the same facility.

Europe supplies a second distinction: a legal right to switch is not the same as a tested exit. The EU Data Act has applied since September 12, 2025 and requires providers of data-processing services to remove specified obstacles to switching; switching charges are scheduled to end on January 12, 2027. But the regulation defines functional equivalence as a minimum based on exportable data and shared features, and its export rules exclude specified provider or third-party intellectual property and trade secrets. An institution still has to test whether its records, configurations, workflows, and evidence can actually be reconstructed elsewhere.

The European Commission's Cloud and AI Development Act, proposed June 3, 2026, is still in the ordinary legislative procedure as of this review; it is not enacted law. Its combination of data-center capacity, public-sector adoption, sustainability, and cloud-sovereignty assessment nonetheless shows the policy problem that Hu helps identify. Locality, electricity, portability, security, and institutional autonomy are not separate topics once the same service binds them together.

The AI-Age Reading

Read in 2026, A Prehistory of the Cloud also reads as a prehistory of AI service delivery. A response appears in a chat window, an image in a panel, a summary in a workspace, or an agent action in another application. That immediacy is produced by distributed facilities, networks, software, labor, and contracts. It is a design achievement, not evidence that the system is self-contained.

The first analytical correction is to separate model, system, and service. The model is a learned computational component. The system adds retrieval, filters, memory, tools, and orchestration. The service adds the endpoint, region, identity provider, telemetry, billing, admin console, support process, subprocessors, and update channel. Safety claims made at one level do not automatically cover the others.

This distinction matters for evidence. A model identifier may not reveal which system prompt, retrieval index, safety policy, routing rule, tool version, or account permission produced an action. A provider status page may document uptime without preserving the records needed to explain an individual decision. A compliance report may describe a control environment while saying little about a customer's particular configuration. The smooth answer is therefore not the unit that must be audited; the service chain is.

AI also changes what remote memory can do. Cloud storage made records available at a distance. Retrieval and agent systems can select those records, summarize them, combine them with new inputs, and act through connected tools. That turns retention, permissions, provenance, and deletion into behavioral controls, not merely storage settings. The relevant companion is the site's account of model memory as an attack surface: captured information acquires new risk when another component can operationalize it.

The failure mode is operational capture. A school, clinic, newsroom, nonprofit, public office, or company believes it has adopted a tool while outsourcing parts of search, memory, identity, records, moderation, incident evidence, and continuity. The decisive question is not whether the system has an inner life. It is who controls the environment in which the institution remembers, decides, and acts—and what happens to the people who must challenge it.

Governance and Safety

The safety unit for cloud-backed AI is the dependency chain, not only the model card or prompt box. NIST SP 800-144 frames public-cloud adoption as the displacement of data and services outside the organization; SP 800-210 shows that the access-control problem changes across IaaS, PaaS, and SaaS. The practical consequence is a responsibility map: for every layer, record what the provider controls, what the customer controls, what is shared, and what cannot be independently verified.

Identity is the first boundary. Name human administrators, service identities, model endpoints, tool credentials, key custody, emergency access, and the party that can revoke each one. For an agentic system, add per-tool scopes, write and payment authority, rate limits, approval thresholds, session boundaries, and a tested stop path. A connector should not inherit a person's entire cloud authority merely because the interface makes authorization easy.

Evidence is the second boundary. CISA's Cloud Security Technical Reference Architecture tells agencies to determine which logs exist, which fields they contain, when they arrive, and how they are stored and retrieved. An AI deployment needs the same discipline for prompts where retained, outputs, tool calls, approvals, configuration changes, model or route identifiers, access events, and incident records. Where retention is lawful and proportionate, essential evidence should not exist only in a provider-controlled console that may change or expire.

Continuity is the third boundary. NIST's voluntary AI Risk Management Framework includes third-party risk, contingency processes, appeal and override, decommissioning, incident response, recovery, and change management. Those outcomes are not a certification that a service is safe. They are prompts for tests: export a representative record set, restore it elsewhere, rotate keys, revoke a connector, preserve an audit trail, run the manual fallback, and document how affected people are notified.

High-consequence use needs an additional public boundary: preservation duties, human appeal, procurement limits on unilateral changes, incident disclosure, independent access to relevant evidence where feasible, and a named official who can suspend use. Data residency alone is insufficient because a region label does not establish every processing, support, backup, telemetry, or legal-access path. A system can be locally hosted and still be institutionally unaccountable.

The Dependency Register

The practical artifact is a cloud dependency register organized around five questions:

  1. Place: Which providers, regions, facilities, replication paths, subprocessors, support locations, and legal jurisdictions can touch each data class?
  2. Authority: Who controls identities, keys, model and policy updates, retention, tool permissions, billing, suspension, and deletion?
  3. Evidence: Which logs, versions, approvals, notices, attestations, and incident records exist, and who can preserve and inspect them?
  4. Continuity: Which data, metadata, configurations, and workflows are exportable; how are they restored; and what manual or alternate-provider mode remains?
  5. Externalities: Which power, water, land, labor, public subsidy, ratepayer, and community obligations make the service possible?

The register matters because working convenience hides transfers of capacity. A school may see a tutor, a clinic a transcription tool, a city a dashboard, and a newsroom a research assistant. Underneath, each may have accepted a remote memory system, credential boundary, audit trail, search layer, security dependency, and update channel. If those dependencies are not named, the institution cannot reliably explain decisions, preserve records, honor deletion, maintain access, or recover when the vendor changes.

Portability should be tested as a process, not inferred from an export button or contractual clause. Before renewal, export a representative record set; verify its schema and metadata; restore it in a clean environment; reconcile counts and permissions; preserve required logs; verify deletion against the stated scope; and time the fallback. The result should include losses and manual work, because a nominally portable archive that cannot reproduce an operational workflow is still a dependency.

The register should sit beside an AI system inventory, procurement file, data-residency assessment, audit-trail record, and change-management log. For public or community-facing systems, it should also feed a proportionate public register. Together, those records make the interface cast an inspectable institutional shadow.

Where the Book Needs Friction

The book's breadth is also its central risk. The cloud can become too elastic when it names networks, storage, platforms, data mining, surveillance, security, military power, and user identity at once. Driscoll is right that the analysis is strongest when attached to a particular route, bunker, account, or system. The remedy is methodological: before applying Hu, name the service model, operator, contract, jurisdiction, affected public, and decision under examination.

Shaviro identifies a second gap: the book gives too little sustained attention to surplus extraction and capital accumulation. Materiality does not by itself explain market power. The same data center can host competitors, a dominant platform can rent rather than own facilities, and cloud credits or proprietary managed services can create dependence without a dramatic physical footprint. A current analysis must follow pricing, financing, ownership, procurement leverage, and switching cost alongside cables and electricity.

There is also a danger in reducing participation to the data it leaves behind. Driscoll's review presses this asymmetry: human association, culture, and public life are not exhausted by the traces a platform captures. That matters for AI analysis. A telemetry record can show a click, prompt, refusal, or correction; it cannot by itself establish the person's purpose, understanding, consent, or social context.

Finally, the book predates accelerator-dense AI facilities, model APIs, retrieval systems, tool-using agents, current cloud-switching law, and large-load reliability proceedings. It should not be made to substitute for a security framework, energy model, procurement rule, or legal analysis. Its best use is diagnostic: it explains why disappearance is consequential and tells the reader which supposedly seamless layer deserves an audit.

What This Changes

The practical lesson is not merely to make infrastructure visible. It is to recognize that every abstraction allocates discretion. A region label lets a provider choose the facilities and routing within a defined offer. A managed model lets a provider choose updates and safety policy. An account lets administrators grant or withdraw access. A dashboard lets its designer decide which costs and failures become measurable. Governance begins by identifying that discretion and deciding which parts require contract, technical control, public record, or law.

That means following the service from data-center permitting and utility planning through procurement, identity, retention, audit access, incident reporting, portability, labor, and exit. It also means preserving the legal role the interface tends to erase. A resident remains entitled to public accountability, a patient to confidentiality, a student to fair process, and a worker to labor protections even when the immediate relationship is mediated by a private account.

The site's recurring concern with feedback becomes concrete here. People act through an interface; those acts become records and operating signals; providers and institutions use the signals to alter models, policies, capacity, and access; the altered system structures the next action. Honest documentation requires preserving enough provenance to reconstruct that cycle. Human agency requires a real point of appeal, override, refusal, and exit within it.

A Prehistory of the Cloud remains valuable because it offers a disciplined suspicion of seamlessness. Translate region into jurisdiction, replication, and energy system; memory into records, permissions, retention, and deletion; agent into credentials, actions, evidence, and liability; and sovereignty into audit rights, exit rights, public capacity, and the practical ability to continue without one provider's permission. The goal is not to abolish abstraction. It is to make consequential abstraction answerable.

Source Discipline

This review separates four source layers. Publication facts and the book's stated scope come from MIT Press and the author's page; interpretive disputes come from named reviews. Technical definitions and controls come from NIST and CISA. Current infrastructure and legal claims come from the IEA, Berkeley Lab, FERC, NERC, the European Commission, and EUR-Lex. The extension from Hu's media theory to cloud-backed AI is this review's argument, not a claim the 2015 book makes about current systems.

Cloud claims need units and boundaries. Data-center electricity is not AI-only electricity. Facility capacity in megawatts is not annual use in terawatt-hours. A projection is not a metered result, and forecasts built from different geographic scopes and models are not automatically comparable. A cloud region is not proof of every processing or access location. A contractual switching right is not a successful migration. A security attestation is not an audit of a customer's configuration, and a sovereignty label is not democratic control.

Procedural status matters too. The June FERC actions are show-cause orders, the July FERC action directs future NERC filings, the May NERC document is a guideline, the Data Act is applicable law, and CADA is a legislative proposal in an ongoing procedure. Collapsing those categories would reproduce the problem under review: distinct institutions and powers disappearing behind one convenient label.

No passage from the book or its reviews is reproduced here beyond titles and short terms necessary for analysis. Current claims were rechecked on August 12, 2026. Grid proceedings, reliability standards, EU legislation, energy outlooks, and provider terms can change, so later readers should follow the linked primary records rather than treating this review date as continuing verification.

Sources

Book links are paid affiliate links. As an Amazon Associate I earn from qualifying purchases.

Buy on Amazon Browse Books

Return to Blog · Return to Books