The Divisibility Problem: The Grid & The Second Industrial Age of Computation
The basic resources modern economies run on eventually go from being a product to becoming a utility: bespoke, then standardized and traded, then drawn from a network and made ubiquitous. The crossing from the second stage to the third is decided by one property: divisibility. Compute took the first step toward stage three in 2006, and has still not arrived.
An essay from LILY Labs
The road every resource has taken
Light was once something you made consciously and with effort. You bought tallow or wax or whale oil, and you made light, badly, at a price that would astonish anyone alive today. At some point it became something you bought in standard grades, sold by volume, graded and interchangeable. Then it became something you simply drew, without thought, by touching a switch on a wall.
That is the road the fundamental inputs to power a civilization take. Bespoke, then commoditized, then a utility. Water traveled it. Gas traveled it. Electricity traveled it, fastest and most consequentially. Telecommunications traveled it.
The first stretch, commoditization, is a story about standardization. A resource stops being particular to its producer and becomes fungible, graded, and tradable. This is genuinely transformative on its own. Markets get created, the cost of comparison collapses, and price discovery occurs. But it leaves something important untouched. A commoditized resource still arrives in lots. You take delivery of a quantity, you store it, and you size your store against your own worst case.
The second stretch is the one that changes how a society lives. It is when a resource acquires a network, a meter, and a fineness of grain that lets you draw exactly what a task needs at the moment it needs it. Then the storage disappears, the buffer disappears, and the bill becomes a record of what you did rather than what you held.
Not every resource makes that second crossing. Oil is the most comprehensively commoditized substance on earth. It gets graded, exchange-traded, hedged, shipped in standard cargoes, and it still has never become a utility anywhere. There is no oil tap in any building in the world. You cannot draw a liter on demand and be billed for the liter. Oil arrives in lots and is stored, exactly as it was a century ago.
What separates the resources that crossed from the ones that did not is divisibility: whether the resource can be subdivided down to the size of the job rather than the size of the delivery. Everything else follows from that one property or fails for want of it. You cannot meter what you cannot subdivide. This essay is about the fact that computation made the first crossing twenty years ago and still has not fully made the second, and about why that has stopped being an inefficiency and started being a constraint.
Before coming to computation, it is worth being exact about what the crossing produces, because the history of utilities is not primarily a history of convenience. It is a history of abundance, and the abundance is measurable.
Take light, the cleanest measured case we have. William Nordhaus, in his 1996 study Do Real-Output and Real-Wage Measures Capture Reality? The History of Lighting Suggests Not, reconstructed the price of illumination across the whole of human history, measured in the labor needed to buy it. A thousand lumen-hours cost a Paleolithic person roughly 58 hours of work gathering wood. By 1800 it cost about 5.4 hours. By 1900, with town gas and the first filaments, about 0.22 hours. By 1992, roughly 0.00012 hours. An hour of work buys something on the order of 350,000 times as much light today as in ancient Babylonia.
The invention of the lightbulb accounts for only part of that. The rest is the network and the meter. Efficiency made light cheaper to produce; utilitization made it available in whatever quantity you wanted, whenever you wanted it, at a grain fine enough that lighting a single room for ten minutes was a sensible thing to do. Today, nobody rations reading lamps.
Samuel Insull, a Londoner who had been Thomas Edison’s private secretary, took over the ailing Chicago Edison in 1892, taking a substantial pay cut to do it. His insight was that the binding variable in the economics of supply was not the price of coal but the load factor, the ratio of average to peak demand. Pool customers whose peaks fall at different hours, and every customer who fills a valley in the load curve makes every other customer cheaper to serve. Streetcars in the morning, factories through the day, homes at dusk. So he chased volume relentlessly: he adopted usage-based metering after seeing it work in Britain, he gambled on the enormous Fisk Street steam turbine in 1903, he financed and gave away appliances to build load, and he absorbed twenty rival utilities by 1907, when the firm became Commonwealth Edison.
The result is one of the most valuable single statistics in the history of infrastructure. The price of residential electricity in Chicago fell from around 20 cents per kilowatt-hour in 1892 to roughly 2.5 cents by about 1909, while the customer base grew from some 5,000 to over 200,000. The price fell by a factor of eight; the customers grew by a factor of forty.
That is what the crossing does. It does not make a resource somewhat cheaper. It makes it cheap enough and fine-grained enough that demand expands to overwhelm the price fall entirely. William Stanley Jevons observed the same effect in The Coal Question in 1865: more efficient steam engines burned more coal, not less, because efficiency made steam economic in places it had never been economic before. The pattern has held in every utility transition since. Cheaper per unit, vastly more units, and a society reorganized around the assumption of abundance.
What decides whether a commoditized resource ever reaches that point is visible in three cases, and in none of them does it turn on the size of the plant.
Water shows the cost of failing on grain. Through most of the nineteenth century, London’s water supply was intermittent. Several private companies, each with its own mains, its own quality, its own prices, pushed water through the pipes for only a few hours on certain days. Households had to catch it and store it in cisterns and butts, each household sizing its own store against its own worst case. Charges were levied not on the volume consumed but on the rateable value of the property. You bought a buffer sized for peak, you maintained it, and you paid for it whether or not it was ever full.
The water was already a commodity in every meaningful sense. What was missing was the ability to draw an arbitrary amount at an arbitrary moment. Until that arrived, every household ran its own storage.
Hydraulic power shows that plant, network and meter are not enough. The London Hydraulic Power Company was a real power utility, and a good one. Incorporated by Acts of Parliament from 1871, with its first station at Falcon Wharf, Bankside, in 1883, it generated power centrally and distributed it through roughly 150 miles of high-pressure cast-iron mains beneath the streets, 180 miles before the war, at around 700 pounds per square inch. Every consumer had a meter. By its peak around 1928 it drove more than 8,000 machines: lifts, cranes, presses, the revolving stages at the Palladium and the Coliseum, the safety curtain at Drury Lane, the backup mechanism of Tower Bridge.
It had the central plant. It had the network. It had the meter. It lost anyway.
It lost to electricity, from about 1904 onward, and it lost for one reason. Hydraulic power was divisible at the main but not at the point of use: you tapped a high-pressure network to drive a discrete machine of a certain minimum size. Electricity was divisible all the way down, to the lamp, to the fractional-horsepower motor, to the smallest task, and it went where pressurized water could not. The more divisible resource won. The last pumping station, at Wapping, closed on 30 June 1977, the final working hydraulic public supply anywhere in the world. Mercury Communications bought the company and reused the pipes as telecommunications ducts. The network of one utility became the conduit of the next.
Factory electrification shows what divisibility is worth once you reorganize around it. Electricity supplied less than a tenth of American manufacturing horsepower in 1900 and roughly four-fifths by 1930, yet the productivity gains arrived late. Paul David explained why in his 1990 paper The Dynamo and the Computer. The first electrified factories bolted an electric motor onto the architecture they already had. Under that arrangement, a single prime mover turned line shafts, belts and pulleys the length of the building. Machines had to sit where the power transmission geometry allowed rather than where the work flowed, and the entire assembly had to spin for any single tool to cut metal. You paid to turn the whole shaft.
What changed everything was unit drive: a small motor on each machine. A machine that was not running consumed nothing. Layouts could follow the work. Fractional-horsepower motors made power divisible down to a single task, delivered exactly where it was needed and only while it was needed. Warren Devine’s From Shafts to Wires (1983) documents the same shift. It took roughly a generation, because the old architecture was not obviously wrong. It was simply inherited. David, not coincidentally, also wrote the canonical paper on path dependence, his 1985 essay Clio and the Economics of QWERTY. Designs outlive the constraints that produced them, and they feel like plain common sense until somebody builds the alternative.
Three cases, one conclusion. Divisibility at the point of use is what decides which infrastructure wins.
Compute made the first crossing and stopped
In 2006 computation became a commodity, and comprehensively so. Two decades later that is not a metaphor but a market structure. GPU-hours have public benchmark indices and brokers. Prices are volatile enough to require hedging: on the Ornn Compute Price Index reported by the Wall Street Journal in April 2026, an hour of a single Nvidia Blackwell GPU reached $4.08, up 48 percent from $2.75 two months earlier. The financial machinery has followed. CME Group and Silicon Data announced in August 2026 plans to list two compute futures contracts on NYMEX in October, pending regulatory review; the Intercontinental Exchange has partnered with Ornn on cash-settled GPU futures. CME’s own framing is that compute is following the road oil took, from spot trading into a derivatives market.
That is the first crossing, complete. What has not happened is the second.
You still take delivery of a lot. The lot is called an instance, a reserved node, a cluster. You provision it, you hold it, and you size it against your own peak, much like a Victorian household sized its cistern. When it sits idle, you pay anyway.
The reason is not that anyone got it wrong. It is that the abstraction was chosen in 2006 for a good reason and never revisited. When EC2 launched, the unit it sold was a virtual server, because a virtual server was the unit customers already knew how to buy, budget for, and reason about. It was a bridge from the on-premise server room to the data center. The bridge did its job. But the industry never finished crossing it, and everything built since has been built on the server-shaped assumption baked in at the start.
What followed was accretion rather than design. Virtualization revived mainframe partitioning to consolidate idle machines. Containers, Linux namespaces and control groups, sliced the machine more finely. Orchestration arrived to manage the containers. Service meshes arrived to manage the orchestration. Serverless was bolted on top to hide all of it. Each layer solved the problem the layer beneath it created, under constraints that were entirely real at the time, and none of them could anticipate what would be stacked above. The cumulative result is that several simulations of “a computer” run on top of one another before a single line of your application logic executes.
The consequences are precise, and each is a symptom of the same missing property.
The provisioning decision did not disappear. It multiplied. You choose instance family and size from hundreds of options, then region, availability zone, node pool, disk type, scaling policy, concurrency ceiling, timeout. Every one of those is a question about a machine. None of them is a question about your application.
The bill records what you held, not what you did. Reserved instances, savings plans, committed-use discounts and spot markets are financial instruments for managing the gap between capacity held and work performed. An entire profession exists to arbitrage that gap.
Even the closest approach is machine-shaped underneath. Cold starts exist precisely because something must locate and boot a container before your code runs. The remedy on sale is provisioned concurrency, paying to keep capacity warm and waiting. That is a cistern, priced by the hour.
The demonstration that this was a choice rather than a law of nature lives inside one company in one year. In March 2006 Amazon launched S3 at a flat $0.15 per gigabyte-month: divisible to the byte, nothing to provision, no idle to pay for, a bill that is a pure record of what you stored. Five months later it previewed EC2 at $0.10 per instance-hour: take delivery of a machine and hold it. Same company, same year, same customers. Object storage made the crossing. Compute did not. The only difference was the grain of the unit.
None of this was for want of a specification. In 1961, at MIT’s centennial, John McCarthy proposed that computing might one day be organized as a public utility, in the way the telephone system is a public utility. It is quoted constantly, and the clause that matters is usually dropped: that each subscriber would pay only for the capacity he actually used, while having access to the resources of a very large system.
Pay only for the capacity actually used is not a billing preference. It presupposes that capacity can be subdivided to the size of the use. That is the divisibility requirement, stated in the first sentence anyone ever wrote on the subject. It was specified in 1961, and the industry has been building around its absence ever since.
McCarthy had already proposed time-sharing at MIT in a 1959 memorandum, work that led to CTSS. Time-sharing was the first serious attempt to make computation divisible: to slice one machine finely enough that many people could draw from it at once. It worked, inside the boundary of a single machine. What it could not do was dispatch a slice of work to any machine. The grain was right and the reach was not.
Five years after McCarthy, and forty years before AWS, Douglas Parkhill published The Challenge of the Computer Utility (Addison-Wesley, 1966). Parkhill was Canadian, at Computing Devices of Canada and later the federal Department of Communications, and his book specifies most of what is now called cloud computing: online access, elastic supply that expands and contracts with demand, the illusion of infinite resources available to any single user, metered pricing, shared infrastructure. Read against the delivered product, Parkhill is the more demanding document. He described elasticity as a property of the resource. What exists is elasticity as a property of a fleet: machines can be added and removed quickly, but the quantum of change is a machine, not a unit of work.
In 1998, Ian Foster, of Argonne National Laboratory and the University of Chicago, and Carl Kesselman, of the USC Information Sciences Institute, published The Grid: Blueprint for a New Computing Infrastructure. They named the vision after the electrical grid deliberately, and set the goal as plainly as it can be set: computation should be as available, and as transparent to the person using it, as electricity drawn from a wall socket. You should not know where it happens, and you should not have to care. Location transparency was the entire point, and it is the requirement the modern cloud fails most conspicuously, since the delivered product asks you to name a region, a zone, an instance family and a placement group before anything can run.
Three years into AWS, the UC Berkeley RAD Lab set out what cloud computing had actually achieved, in Above the Clouds: A Berkeley View of Cloud Computing (Technical Report UCB/EECS-2009-28, February 2009): the illusion of infinite resources on demand, the elimination of up-front commitment, and the ability to pay for resources on a short-term basis and release them when done. Note the unit in that last clause. Resources, released when done. Even the most rigorous contemporary assessment described release-when-done at the granularity of a rented machine, because a machine was the only granularity on offer.
Set the specifications against what shipped.
This is not three different failures. It is one failure, three times. In every case the specification described a resource and the implementation delivered a machine. The reserved instance, the idle capacity, the cost-management profession, the cold start all descend from that single substitution.
The theorists were not wrong and the engineers were not lazy. The missing piece was never the vision; it was the unit of execution. You cannot dispatch a machine image to arbitrary free capacity, because a machine image is bound to a machine. Until the compiled unit of work became independent of the hardware it runs on, location transparency was unbuildable, and every attempt had to fall back on shipping a virtual machine and asking the customer where to put it.
There is an irony in where the substitute came from. In 1997, Edouard Bugnion, Scott Devine, Kinshuk Govil and Mendel Rosenblum, at Stanford, published Disco: Running Commodity Operating Systems on Scalable Multiprocessors. The following year Rosenblum, Devine, Bugnion, Diane Greene and Edward Wang founded VMware. It was excellent engineering aimed at a real problem: how to run existing operating systems on hardware they were never designed for, without rewriting them. Virtualization was a bridge, a way to carry the installed base across to new machines.
The bridge became the foundation. Twenty-eight years later, virtualization is not a transitional device but the load-bearing assumption of the industry. Containers, orchestration, service meshes and serverless all sit on a mechanism designed to avoid changing anything. McCarthy specified a resource you draw. Rosenblum built a way to keep selling machines. The workaround won for thirty years, for good reasons: it worked, it asked nobody to rewrite anything, and hardware got cheap fast enough to absorb the overhead. Those reasons have expired.
The subdivision of the electric light
In every one of the crossings described above, the central plant and the network existed before the resource became a utility. London had waterworks long before it had taps. Chicago had generating stations before it had lamps in ordinary houses. What changed things each time was the arrival of a small, cheap, independently controllable device at the point of use. The tap. The burner. The fractional-horsepower motor. The generating station gets the credit; the endpoint did the work.
The electrical case is the sharpest, because the problem had a name. In the 1870s the arc lamp was the only practical electric light, and it was enormous: thousands of candlepower, wired in series so that a whole circuit was on or off together, suitable for a street and useless for a room. Making electric light usable at domestic scale was known at the time as the subdivision of the electric light, and the consensus of the profession was that it could not be done. William Preece, chief engineer of the British Post Office and the most senior electrical engineer in the country, ranked the subdivision of light with perpetual motion, squaring the circle and the transmutation of metals, and concluded that electricity would not supplant gas in the home.
Preece was not a fool. He was reasoning correctly about the topology everyone had, which was a series circuit. Edison’s answer was a high-resistance filament wired in parallel: high resistance meaning low current, meaning economically thin copper, and parallel meaning every lamp independently switchable without disturbing any other. The plant did not change. The endpoint did, and with it everything downstream.
We think this is the fairest available description of where cloud infrastructure now sits. Nobody in the industry is wrong or idle. A generation of genuinely excellent engineers is reasoning correctly about a series-shaped stack, one in which the smallest thing you can start, stop, place or bill is a simulated machine, and everything built above inherits that minimum size. Containers made the machine smaller. Orchestration made many machines manageable. Serverless made the machine briefer. None of them made the unit smaller than a machine, because none of them could: the endpoint was fixed in 2006, and every layer since has been built to accommodate it.
Changing the endpoint
Our own work is an attempt to move the floor.
Software today is usually operated as a block. A program lives inside a deployment unit, that unit runs on infrastructure, and most operational decisions are made at the level of the whole thing. If one part of the application becomes hot, the usual answer is to scale the surrounding block with it.
LILY takes a different direction. The platform is designed around a smaller unit of application work, so the user does not have to think first in machines, node pools, regions or orchestration layers. Publicly, that is the level of detail worth sharing: the system aims to make the application the unit of deployment, not the machine.
The customer-facing result is simpler. Deployment begins with a repository. The system discovers what can be run and asks the human the application-level questions that still require judgment: which application to run and how it should be configured. Those are product questions, not machine questions.
That is what the location-transparency requirement actually asks for. The user should not have to name an instance family, operate a cluster, or maintain a control plane in order to ship software. The platform can have machinery underneath; the product promise is that the customer should not have to own it.
And what the smaller unit buys is operational efficiency without making the customer study the internals. LILY's public claim is not a diagram of the system. It is that less infrastructure surface can mean less waste, less maintenance, and more attention left for the application itself.
Which brings us to the claim this essay has been walking toward, and we want to state it precisely rather than expansively.
The divisibility criterion, the ability to draw computation at the grain of the work rather than the grain of the machine, with nothing held in reserve and no buffer sized against a peak, has never been met in the history of computation. Not by time-sharing, which subdivided a single machine beautifully and could not reach past its own chassis. Not by the service bureaus, which centralized the plant and required you to carry your work to it. Not by application service providers, or by grid computing, or by Sun’s dollar-per-CPU-hour Sun Grid, which launched in March 2006 and struggled almost immediately. Not by AWS, whose object storage crossed and whose compute did not. Not by containers, which sliced the machine thinner. Nor by serverless, which made it briefer. In sixty-five years every implementation has delivered a machine, because a machine was the smallest thing anyone could ship.
We are trying to move past that:
The important distinction is simple: the user should not have to deploy a machine in order to run an application. Nobody names a region, an instance family or a node pool in the normal product flow. The two questions the system asks a human are which applications to run and how to configure them, and both are questions about the application rather than about a machine.
Compute may never be as fungible as a kilowatt-hour: models have data gravity, latency has geography, and an accelerator-hour in one facility is not freely interchangeable with another. Electricity had genuine natural-monopoly economics that compute may not share, so the historical parallel guides intuition without guaranteeing the outcome.
The specification has not moved in sixty-five years, and has gone unmet for all of them: McCarthy’s metered capacity, Parkhill’s elastic supply, Foster and Kesselman’s location transparency. The vision was never the problem. The endpoint was, because you cannot dispatch a machine to arbitrary free capacity, and a machine was all anyone had to dispatch.
As the atomic unit of each application, the Brick is the device to change that. For the first time since McCarthy described it, the grain of the unit matches the grain of the work, and computation, sixty-five years later, is about to reach that stage.
You build. We carry.
Start for free. Read the docs. Talk to us about migrating a workload.