The Cloud Was Built for a World That No Longer Exists
Cloudflare's S-1 filing opens with a pointed observation: “The Internet was not built for what it has become.” The same logic applies to the cloud. Early services like Amazon EC2 were a genuine improvement over buying and racking physical servers, but they were essentially virtualizations of the old model—not a rethinking of what computing should be. It’s the equivalent of replacing steam locomotives with electric engines that still require a chimney and scheduled water stops.
The rituals of the traditional cloud—choosing regions, provisioning VMs, keeping code artificially warm—are just modern versions of those legacy constraints. But glimpses of a different model have emerged over time: lambdas, edges, functions, serverless. These terms all point toward a way of computing that says: write code, we’ll run it, don’t sweat the details like scaling or location. We call that the Supercloud.
The Supercloud is built on compute and data services that make running applications efficient and infinitely scalable, without the baggage of the cloud as it exists today.
Granularity Is the Foundation
The NoSQL movement was an early push toward granularity in data. Rather than thinking in terms of databases, tables, or rows, key-value stores and document stores created a direct connection between code and data at a simpler level. Object stores like R2 follow the same logic. MapReduce similarly broke data processing into discrete, scalable pieces, making it possible to handle enormous datasets efficiently.
The same shift is now happening for code. Programmers shouldn’t have to think in VM- or container-sized chunks any more than they should think in database-sized chunks. That kind of overhead has nothing to do with writing a service; it distracts from the actual value of creating something.
Distributed programming theory has long pointed in this direction. The CSP model uses tiny processes that pass data (and inspired Go), the Actor model has messages flowing between actors that maintain internal state, and the lambda calculus is built on discrete functions acting on data. CORBA even introduced the idea of an object request broker, letting objects run remotely without the developer knowing where or how they execute. The theory consistently moves away from dedicated machines and toward code and data that run automatically, with execution and data locality handled efficiently underneath.
What the Supercloud Changes
Scaling is the most obvious difference. No one needs to decide how many VMs to provision or keep hot standbys waiting for traffic spikes. General-purpose computing should scale up and down the way MapReduce does, with no idle capacity and no wasted expense.
Code and data also become mobile. Attach data to code the way Durable Objects do—the Actor model made real—and applications can scale to any size and move close to users when performance demands it. If data truly can’t move, the code moves to the data, no matter how many times access is needed.
This flexibility has direct implications for privacy and data residency. Code that enforces a law about where data can be processed or stored can operate at the level of individual users or objects. The same code can behave differently—even execute in a different country—based on where its associated data lives.
Efficiency by Design
The Supercloud changes the economics of running a program in two ways. First, it’s more economical because you only run what you need. There are no committed VMs idling in anticipation of work, no paying for machines that are standing by. Code either runs or it doesn’t, and you pay only for what you use.
Second, it forces the compute platform itself to be as efficient as possible. Code must start quickly for performance and scale. CPUs must be used fully because no customer is paying to keep idle ones around. That efficiency is better for the environment—cloud machines run at very high utilization—and it’s what allows the platform to handle the 10 million requests that Cloudflare Workers processed in the time it took to read the last sentence.
This model scales well beyond a single machine, data center, or country. With the right software, the platform scales to the size of the Internet. Software allocates resources automatically across the globe, moving connections, data, and processing to wherever they’re needed most.
Welcome to the Supercloud
The result is a cloud that is performant, scalable, available, private, and cost-efficient. The old rituals—choosing a region, provisioning VMs, auto-scaling containers, worrying about cold starts—start to look ridiculous, anachronistic, and expensive.
Cloudflare has been building the alternative to that traditional model directly into its network and developer platform for years. The term “Supercloud” may be new, but the underlying infrastructure is real: over a million developers are building on it today. The platform has been in development for 12 years, and five years ago it opened up to developers through Cloudflare Workers, which was built for scale and performance from day one by running on the global network.
With that, welcome to the Supercloud and welcome to Cloudflare Developer Week 2022. Over the coming days, we’ll be announcing more building blocks for the platform. Many of the tools themselves are built on Workers, and this week we’ll show not just what you can build, but how we built these tools and how customers are using them in production today.
