The Birth of Cloud Computing: From MIT Time-Sharing to Hyperscalers

1961: Computing as a Utility

In 1961, John McCarthy — the computer scientist who coined the term “artificial intelligence” — gave a speech at MIT’s centennial celebration. He predicted that computing would one day be organised as a public utility, the same way electricity and water are delivered. You wouldn’t own a computer any more than you own a power station. You’d just use computing when you needed it and pay for what you consumed.

It took 45 years for AWS to prove him right. But the work started immediately.

CTSS: The Compatible Time-Sharing System (1961)

MIT’s computation centre had a problem. They had an IBM 7094 mainframe — one of the most powerful computers in the world at the time — and it could only run one program at a time. Researchers would submit jobs on punch cards, wait hours or days for their turn, and get their results back. The machine was phenomenally expensive and sat idle between jobs.

Fernando Corbató and his team at MIT built CTSS — the Compatible Time-Sharing System. Instead of one user at a time, CTSS rapidly switched between multiple users, giving each one the illusion of having the entire machine to themselves. A researcher at a terminal could type a command, get a response, and interact with the computer in real time. Multiple users, simultaneously, on one machine.

This was cloud computing. Not branded, not marketed, not running on commodity hardware in a datacentre — but conceptually identical. Multiple users sharing a pool of compute resources, each isolated from the others, each paying (in this case, through grant funding) for what they used. The idea that a computing resource doesn’t need to be owned to be used — that’s the entire foundation of cloud.

Project MAC and Multics (1963-1969)

DARPA funded MIT’s Project MAC (Multiple Access Computer, or Machine-Aided Cognition — they never quite settled on the acronym) to push time-sharing further. This led to Multics — the Multiplexed Information and Computing Service — developed jointly by MIT, Bell Labs, and General Electric.

Multics was wildly ambitious. It aimed to create a computing utility that would serve an entire community of users, with robust security, a hierarchical file system, dynamic linking, and hot-swappable hardware. It was supposed to be the operating system that made McCarthy’s vision real.

Commercially, Multics was a failure. It was over-engineered, over-budget, and late. Bell Labs pulled out of the project in 1969.

But its influence was enormous. Two Bell Labs researchers who’d worked on Multics — Ken Thompson and Dennis Ritchie — took the concepts they’d learned and built something simpler. They called it Unix. And Unix, in various forms, now runs virtually every server on the internet, every Android phone, every Mac, and most of the cloud infrastructure on the planet.

Multics failed as a product. As a set of ideas, it succeeded beyond anything its creators imagined.

IBM and the Invention of Virtualisation

While MIT was building time-sharing operating systems, IBM was solving the same problem from a different angle: virtualisation.

In 1966, IBM’s Cambridge Scientific Center built CP-40 — a system that could create multiple virtual machines on a single physical IBM System/360 mainframe. Each virtual machine was a complete, isolated instance of the hardware. Users didn’t share an operating system — each one got their own entire machine, virtually.

This was a fundamentally different approach from time-sharing. Time-sharing systems like CTSS shared one operating system among many users. CP-40 gave each user their own operating system running on virtual hardware. If your virtual machine crashed, nobody else was affected. The isolation was complete.

CP-40 led to CP-67, then to VM/370 in 1972 — the first commercially available hypervisor. IBM sold it for decades. Mainframe customers could run multiple operating systems simultaneously on a single machine, each in its own virtual machine, each completely isolated.

Sound familiar? This is exactly what VMware does. It’s exactly what Hyper-V does. It’s exactly what Proxmox does. It’s exactly what EC2 does. The concept hasn’t changed since 1966 — a hypervisor creates virtual hardware, you install an operating system on it, and the virtual machine thinks it’s running on real hardware.

For thirty years, virtualisation was an IBM mainframe thing. Expensive. Enterprise. Not something you’d encounter outside a large datacentre. That changed in 1998.

The Timeline: From Mainframes to Hyperscalers

VMware: Virtualisation Leaves the Mainframe

For three decades, virtualisation was something you did on IBM mainframes that cost more than houses. Then, in 1998, VMware was founded with a radical premise: virtualise x86 hardware. Run virtual machines on the same commodity servers that every company already owned.

This was the inflection point. Suddenly, a company didn’t need to buy 10 physical servers for 10 workloads. They could buy 2 beefy servers, run VMware’s hypervisor, and create 10 virtual machines. Server utilisation went from 10-15% to 60-80%. The economics were transformative.

VMware’s vSphere/ESXi became the standard in enterprise datacentres throughout the 2000s. If you worked in IT infrastructure between 2005 and 2020, you used VMware. It was practically mandatory.

Then Broadcom acquired VMware in 2023 and changed the licensing. Prices skyrocketed. Enterprise customers who’d been locked in for decades started looking for alternatives. Proxmox, which had been quietly building an open-source virtualisation platform since 2008, suddenly had a massive audience. The VMware exodus is still happening in 2026, and it’s why learning Proxmox is one of the most career-relevant things you can do right now.

AWS: Selling Spare Capacity

The story of AWS is, at its core, a story about spare capacity. Amazon built massive computing infrastructure to handle peak shopping traffic — Black Friday, Prime Day. For the other 360 days of the year, most of that capacity sat idle.

Jeff Bezos’s insight was that this spare capacity could be sold. In 2006, AWS launched Elastic Compute Cloud (EC2), offering virtual machines by the hour. No upfront cost. No long-term commitment. Spin up a server in minutes, use it for an hour, shut it down. Pay only for what you use.

This was John McCarthy’s 1961 prediction made real. Computing as a utility. Not owned, but consumed. And it used the same fundamental technology IBM invented in 1966 — a hypervisor creating virtual machines on physical hardware. AWS’s initial hypervisor was a modified version of Xen, the open-source project from Cambridge.

Microsoft followed with Azure (preview 2008, GA 2010). Google launched Google Cloud Platform in 2008. By 2015, the cloud market was dominated by these three — AWS with roughly 30% market share, Azure around 20%, and Google Cloud around 10%.

OpenStack: The Open-Source Cloud That Almost Was

In 2010, NASA and Rackspace open-sourced their cloud platforms — NASA’s Nebula and Rackspace’s Cloud Files — merging them into OpenStack. The promise was compelling: an open-source alternative to AWS that you could run on your own hardware. Your own cloud, with no vendor lock-in.

OpenStack gained enormous momentum. Major companies contributed — IBM, HP, Red Hat, Intel, Canonical. For several years, it looked like the future of private cloud.

In practice, OpenStack proved incredibly complex to deploy and operate. It had hundreds of configuration options, dozens of interacting services, and required significant expertise to maintain. Companies that tried to run their own OpenStack clouds often found that the operational overhead eliminated the cost savings. Many migrated back to AWS or Azure.

OpenStack survives today in large telcos, research institutions, and some enterprises with the engineering depth to operate it. But it never achieved its goal of becoming the Linux of cloud computing — accessible, ubiquitous, and easy to run.

Containers: The Next Abstraction

Virtual machines solved the server utilisation problem, but they carried overhead. Each VM runs its own operating system — its own kernel, its own system services, its own memory footprint. Running 10 VMs means running 10 copies of Linux (or Windows), even if they’re all running the same application.

Containers solved this by sharing the host’s kernel. A container includes only the application and its dependencies — not an entire operating system. This makes containers smaller (megabytes instead of gigabytes), faster to start (seconds instead of minutes), and more efficient with resources.

The concept isn’t new — Linux had kernel-level isolation mechanisms (cgroups, namespaces) since 2008. But Docker, launched in 2013, made containers accessible. A Dockerfile describes your application’s environment. docker build packages it. docker run starts it. Anyone with Docker installed can run your container and get identical results. “Works on my machine” became “works on every machine.”

Docker made containers easy. Kubernetes, released by Google in 2014, made them manageable at scale. Google had been running containers internally for over a decade using a system called Borg. Kubernetes (Greek for “helmsman”) was Borg’s concepts made public — container scheduling, service discovery, self-healing, rolling deployments, declarative configuration.

Today, Kubernetes is the de facto standard for container orchestration. EKS (AWS), AKS (Azure), GKE (Google Cloud) are all managed Kubernetes. If you’re building anything at scale in 2026, you’re probably running it on Kubernetes. And if you want to learn it on your own hardware, K3s on a Raspberry Pi teaches the same concepts without the cloud bill.

The Centralisation Aberration

Here’s the part that rarely gets discussed in cloud marketing: the original vision was distributed computing. Time-sharing was about sharing resources across a community. The internet was designed with no central point of control. Open-source software was built to be run by anyone, anywhere.

The current reality — where three companies control the majority of the world’s cloud compute, where a single region outage takes down half the internet’s services, where your data lives on hardware you don’t own in a country whose laws you didn’t agree to — is not the natural evolution of these ideas. It’s a centralisation driven by economics and convenience, not by technical necessity.

Every tool you need to run your own infrastructure exists, is open source, and runs on hardware you can buy for a few hundred pounds:

• Hypervisor: Proxmox VE — free, open source, more than capable
• Containers: Docker — the same containerisation technology that runs in every cloud
• Orchestration: K3s — Kubernetes on commodity hardware
• Automation: n8n — self-hosted workflow automation
• Monitoring: Uptime Kuma + Grafana + Prometheus — production-grade observability
• Storage: Nextcloud, MinIO — your files, your hardware

Self-hosting isn’t a step backwards from the cloud. It’s a return to the original vision — computing as a resource you control, running on infrastructure you own, using open technology that anyone can audit and modify. The hyperscalers are the deviation. The homelab is the tradition.