The Origin of Public Cloud: From a 1961 Lecture to a Trillion-Dollar Industry

On 4 April 1961, Professor John McCarthy stood in front of MIT's Centennial audience and made a prediction that sounded like science fiction. "Computation," he said, "may someday be organised as a public utility." Like electricity from the wall, computing power would one day flow on demand, billed for what you used, available to anyone who plugged in.

It took forty-five years for that prediction to become reality. The story of how it happened is not a story about technology alone. It is a story about timing, about bandwidth, about a few extraordinary thinkers, and about one online bookseller who needed so much computing infrastructure that he decided to rent it out to the rest of the world.

Why this category had to exist

By 2005, running enterprise IT had become a slow, capital-intensive, and structurally inflexible exercise. A small group of engineers at Amazon looked at the problems below and decided that infrastructure should be rented like electricity, not owned like real estate.

• <strong>Massive upfront capital expenditure.</strong> Servers, storage arrays, and networking gear required millions in CapEx before a single line of business code could run. Enterprises were locked into three-to-five-year hardware refresh cycles regardless of whether the business grew, shrank, or pivoted.
• <strong>Capacity that always missed reality.</strong> Sized for peak load, infrastructure ran at 10 to 15 percent average utilisation. Sized for average, the business crashed during year-end close or a marketing campaign. Either way, the capital allocation was wrong.
• <strong>Backup and DR doubled the bill.</strong> A 100-terabyte primary estate meant 100 terabytes of backup gear, another off-site copy, and often a full DR-ready secondary infrastructure. The duplicate-everything model made resilience economically painful.
• <strong>Specialist staff in every silo.</strong> A modern data centre required dedicated storage admins, network engineers, DBAs, virtualisation specialists, and security operators. Hiring, retaining, and training them was a continuous and expensive battle.
• <strong>Six-week provisioning cycles.</strong> Standing up a new workload meant ordering hardware, racking it, cabling it, imaging it, and handing it off. Developers watched competitors ship in days using rented infrastructure and started asking why their own IT could not.
• <strong>Power, cooling, and real estate.</strong> The physical building itself, the diesel generators, the UPS rooms, the chilled-water plants, the security guards, all of it had to be funded and maintained just to keep the silicon running. None of it produced direct business value.

Chapter 1 (1961-1995): The Utility Computing Dream

McCarthy's prediction did not come from nowhere. By 1961, computing was already a shared resource in academic circles. Time-sharing systems like MIT's CTSS allowed multiple users to access a single mainframe simultaneously, an early hint that compute could be a service rather than a possession. J.C.R. Licklider, the visionary who funded the early ARPANET, wrote in 1963 about an "Intergalactic Computer Network" where users could log in to any machine from anywhere and access any resource.

But the technology of the era could not deliver on the dream. Mainframes were room-sized and tied to specific buildings. Bandwidth between cities was measured in kilobits per second. Long-distance computing existed, but it was expensive, fragile, and the exclusive domain of universities and the military. The utility-computing idea hibernated for three decades while the personal computer revolution carried the industry in the opposite direction. By the late 1990s, computing had moved from rooms full of shared mainframes to individual desktops, exactly the reverse of McCarthy's prediction.

The internet changed the trajectory again. By 1995 the web was commercial and broadband was beginning to spread. A new question emerged: if you could deliver any application through a browser, did the user still need to own the application? And if not, did they really need to own the server it ran on?

Chapter 2 (1999): Salesforce and the SaaS Spark

In March 1999, a former Oracle executive named Marc Benioff founded a company in a one-bedroom San Francisco apartment with a deliberately provocative slogan: "No Software." Salesforce delivered customer relationship management entirely through a web browser, billed by the user per month, with no installation, no servers, no upgrades. It was the application service provider (ASP) model executed properly, by people who actually believed in it.

Salesforce was not the first SaaS company, but it became the most consequential. By 2003 it was profitable. By 2004 it was public. By 2008 it had crossed a billion dollars in revenue. More importantly, it had proven a thesis that most of the technology industry still resisted: enterprises would happily run mission-critical business processes on infrastructure they did not own, did not see, and did not control, as long as the software just worked.

Salesforce was the application layer of the cloud before the infrastructure layer existed. It proved customers were ready. The infrastructure was about to follow.

Chapter 3 (2000-2006): Amazon Builds the Plumbing

In 2000, Amazon was a struggling online bookseller. Its engineering teams were drowning under a different problem: every new product or feature required months of infrastructure provisioning, racking servers, configuring storage, allocating databases. Jeff Bezos issued a now-famous internal mandate in 2002. Every team must expose its services as APIs. Every team must be able to consume any other team's services purely through those APIs. There would be no exceptions.

The mandate had a strategic side effect that nobody at Amazon initially appreciated. As internal services became clean, standardised, network-accessible APIs, the same services could in principle be exposed to the outside world. By 2003, a small group at Amazon began arguing that the company should rent its excess infrastructure capacity to other businesses. Inside the company, the idea was treated as a distraction. Bezos backed it anyway.

On 14 March 2006, Amazon launched Simple Storage Service (S3). On 25 August 2006, it launched Elastic Compute Cloud (EC2). Together they offered something no commercial product had ever offered: pay-as-you-go computing and storage, provisioned in minutes through an API, billed by the hour, with no contract, no minimum commitment, and no salesperson. The age of public cloud had begun, and the company that started it was not IBM, not HP, not Microsoft, not Sun, but a bookstore.

Chapter 4 (2008-2013): The Hyperscalers Wake Up

For two years AWS had the public cloud market essentially to itself. The technology incumbents dismissed it. Larry Ellison memorably called cloud "complete gibberish." That changed quickly. In April 2008, Google launched App Engine, a platform-as-a-service offering aimed at developers. In October 2008, Microsoft announced Windows Azure (renamed Microsoft Azure in 2014), with general availability in February 2010.

By 2011, IBM, HP, Oracle, and VMware were all in the public cloud game in some form. Most of those attempts failed. Public cloud was not just a different product. It was a different operating model, a different cost structure, a different sales motion, and a different relationship with customers. Companies built around licensed software and quarterly enterprise sales could not easily reinvent themselves around a pay-per-second self-service API.

Meanwhile AWS, Azure, and Google Cloud kept widening their lead. AWS reached one million active customers by 2014. By 2015 Amazon broke out AWS revenue for the first time: $7.88 billion that year, growing 70 percent year over year, with margins that dwarfed the retail business. The board-level conversation across every Fortune 500 changed overnight. Cloud was no longer a developer curiosity. It was the strategic infrastructure question of the decade.

Chapter 5 (2014-2020): Cloud Becomes the Default

The mid-2010s turned cloud from a tactical option into the default architecture for new applications. Containers, formalised by Docker in 2013 and orchestrated by Kubernetes from 2015 onward, made cloud workloads portable. Serverless computing arrived with AWS Lambda in 2014, abstracting infrastructure even further. Machine learning workloads, which required vast bursts of GPU compute, were impossible to run economically on owned hardware and pushed entire data-science teams onto cloud as a matter of necessity.

Regional expansion accelerated. AWS launched its Middle East (Bahrain) region in 2019, Microsoft opened UAE Central and UAE North Azure regions in 2019, and Google Cloud added Dammam (Saudi Arabia) in 2022. For the first time, regulated UAE workloads could run in public cloud without leaving the GCC. Sovereign cloud frameworks emerged, with hyperscalers operating under strict data-residency constraints aligned to NESA, ICA, and ADHICS.

By 2020, Gartner reported that 80 percent of enterprises were using public cloud in some form. The conversation in boardrooms had inverted. The question was no longer "should we move to cloud?" but "what justifies us staying off cloud for this workload?"

Chapter 6 (2022-now): The AI Cloud Era

The generative AI boom that followed the release of ChatGPT in November 2022 cemented public cloud as the indispensable platform of the modern era. Training a frontier large language model requires thousands of GPUs running in parallel for weeks, an infrastructure scale that no enterprise builds for itself. The hyperscalers became the gatekeepers of AI capacity. Amazon Bedrock, Azure OpenAI Service, and Google Vertex AI emerged as the primary commercial channels for accessing leading models.

GPU scarcity reshaped the cloud economics. AWS, Azure, and Google announced waiting lists. Capital-expenditure cycles for new data-centre construction shortened from years to months. Sovereign AI initiatives, including the UAE's investments in domestic compute capacity, became matters of national strategy.

What McCarthy described in 1961 as a public utility has arrived in a form he could not have predicted. Computing flows on demand, billed by the second, but the workload running through that pipe is no longer payroll or inventory. It is an artificial intelligence trained on a meaningful fraction of recorded human knowledge. The cloud is no longer just infrastructure. It is the substrate on which the next era of software is being built.

What This Means for UAE Businesses Today

If you are making cloud decisions in the UAE in 2026, the history above matters in four practical ways. First, the public cloud is no longer a single product category. AWS, Azure, and Google Cloud each have their own strengths, and the right answer for an Abu Dhabi bank looks very different from the right answer for a Dubai retailer or a Sharjah manufacturer. Workload, regulatory exposure, and existing skills must drive the choice.

Second, data residency is now a solved problem. UAE Azure and Bahrain AWS regions allow regulated workloads to run on hyperscaler infrastructure without leaving the GCC. The compliance arguments that justified staying off cloud in 2017 no longer hold. The remaining objections are architectural and operational, not regulatory.

Third, the economic model has matured. Cloud was once cheaper than on-premise; today it can be either cheaper or more expensive depending on workload pattern, commitment level, and FinOps discipline. The teams that win in public cloud are the ones that treat cost as an engineering problem, not an invoice problem.

Fourth, AI has changed the strategic calculus. If your medium-term roadmap involves any meaningful AI workload, your cloud provider is also your AI provider. That decision deserves more deliberation than it usually gets.

Where Artiflex IT Comes In

Artiflex IT has been designing, deploying, and managing cloud solutions across the UAE, Oman, and Saudi Arabia for over 14 years. We work with AWS, Microsoft Azure, Google Cloud, VMware, Nutanix, Veeam, Zerto, and the broader cloud ecosystem as the use case requires. We do not believe one platform wins every workload, but we do believe the right platform for a specific workload usually wins by a meaningful margin once the assessment is done honestly.

If you are partway through a cloud journey and not sure whether the next step is more public cloud, more private cloud, more hybrid integration, or something else entirely, we will tell you exactly what your current state looks like and what an honest plan for the next 18 months should be. No upselling, no theatre.