LILY Margin Notes, part 1: The technologies that disappear

A technology has reached maturity when people stop noticing it. Writing passed that test short after Gutenbergs reimagination of the porinting press, and so did the electric motor at some point. The system your software runs on never has, subsequent innovations may have added complexity.

An essay from LILY Labs

Count the electric motors in your home. There is one in the fridge, two in the washing machine, then the extractor fan, the hair dryer, the toothbrush, the blender, the fan in the laptop and many many more. Most people are off by about half the actual amount.

The electric motor might be the most successful machine of the twentieth century, yet in our day to day lives, it fades into obscurity.

Mark Weiser, head of the Computer Science Laboratory at Xerox PARC, made the same count for a car in 1991: 22 motors and 25 solenoids in a typical shop manual. He was writing about computers, in Scientific American, and his first sentence founded a field: "The most profound technologies are those that disappear."

Thirty-five years on, his test is worth applying to a machine that has had every chance to disappear and has not taken it: the one that runs your software.

Not hidden, unnoticed

Weiser's first example was writing. It can be found everywhere, from street signs, over labels to sweet wrappers. It simply feels natural. You take in a street sign without performing the act of reading. The computer of 1991, by contrast, had sold 50 million units and still lived in a world of its own, reachable only through jargon. He compared it to the age when a scribe had to know as much about ink and clay as about writing.

Disappearing, in his sense, is not achieved by hiding the device. It is a psychological phenomenon: once people learn something well enough, they stop being aware of it, and only then are they free to look past it at new goals. The way we serve software to our customers has not yet caught up to this standard and remains archaic as well as overtly complex. Something, even a trained professional has to put thought into, a circumstance we deem inacceptable.

The test is simple: Does the technology ask for your attention at the point of use?

From shafts to wires

The motor did not disappear when it was invented. It took about forty years, and the reason is the useful part.

Warren Devine, of the Institute for Energy Analysis in Oak Ridge, told the story in 1983 in From Shafts to Wires, in the Journal of Economic History. A factory of 1890 ran on one steam engine turning iron line shafts along the ceiling of every floor. Belts dropped from the shafts to each machine, so the machines stood in rows. The whole network turned from morning to night, whether one machine was working or a hundred. If a shaft broke, a room stopped. Operators spent part of every day filling drip oilers and re-lacing belts.

When electric motors arrived in 1883, factories unbolted the steam engine, bolted a motor in its place and left everything else alone. In 1895, a mill at Taftville, Connecticut, had one motor driving 1,200 looms. Then came group drive: shorter shafts, one motor each. Then unit drive: a motor on every machine, and no shaft at all.

Engineers argued against unit drive for a decade, and correctly. It needed five to seven times the motor capacity of group drive. It did not matter. Nothing turned idle, the floor could follow the work instead of the shaft, and factory reports collected by F. B. Crocker of Columbia in 1901 showed output up 20 to 30 percent with the same floor space, machines and workers. Electric drive went from under 5 percent of mechanical drive capacity in American manufacturing in 1899 to about 78 percent in 1929. Output per worker-hour, which had grown 1.3 percent a year before 1919, grew 3.1 percent a year after.

Devine's conclusion is Weiser's test, passed. Once each machine had its own motor, manufacturers stopped thinking about power and thought about production. The motor vanished when its unit matched the unit of the work.

From steam machines to data centers

An instance is a server rented by the hour. You still choose its size, region and disk, and it still turns whether it serves traffic or not. In our article Billed Before the First Request we we highlighted the cost of that idle turning. Containers and orchestrators are group drive: workloads share a machine sized for the group, and a scheduler moves work between shafts. A real improvement, and still a shaft someone has to tend.

The tending shows in the surveys. In the Cloud Native Computing Foundation's 2025 survey of 628 practitioners, published in January 2026, 82 percent of container users run Kubernetes in production, and 34 percent still name complexity as a challenge, twelve years after it shipped. It has not disappeared. It has been learned.

In Set and forget we argued that the hours now go to keeping software alive rather than writing it. This piece asks why they are still being asked for. Apply Weiser's test. A pager exists to demand attention. An expiring certificate, a node to drain before a patch, an autoscaling rule to retune: each is a drip oiler. And the scribe is back. A developer who wants an application to run is expected to know node pools, ingress rules and readiness probes. That is the ink and the clay.

What still demands attention

Age is not the reason. Hypervisors date from the 1960s. Distance is not the reason either: the server moved into a building you will never visit and stayed in view anyway.

The motor suggests a better one. A technology disappears when the unit you buy is the unit you use. Buy a motor per tool and attention stops at the tool. Buy a shaft and it is everyone's problem, because every tool depends on it and none owns it.

In computing, the unit you use is a request, a function, a job. The unit you buy is an instance, a node, a cluster. Everything between those sizes is belting: autoscalers, schedulers, capacity plans. Belting has to be oiled.

Serverless saw this and solved the half it could reach. It billed by the millisecond and took the machine's name off the invoice, the right trade for many workloads. But you still pick a memory size, set a concurrency ceiling and mind the cold start. Hidden is not the same as disappeared.

Try this. List every alert your production system sent last month that needed no decision from anyone. Those are the drip oilers.

The exception validates the principle

Some infrastructure should not disappear: what it costs, where the data sits and under whose law, what happens when it fails. Weiser himself warned that whatever leaves attention also leaves scrutiny. The answer is a threshold. Visible where a human decision changes the outcome, invisible everywhere else. Where your customers' data lives is a decision. Which node restarts a container at three in the morning is not. Today's platforms show you the oiler, not the ledger.

The second objection is Weiser's own. Disappearance happens through learning, so for a platform team ten years in, the cluster has disappeared. True, for the specialist. Never for the person who just wanted the software to run. And here the motor analogy has a limit. A motor stays the same for thirty years, which is what lets it be learned into invisibility. A platform that changes every week never settles long enough to be learned that way.

When it stops asking

Back to the motors in your home. You undercounted them because none has asked you for anything this year. The infrastructure under your software asks every week. That is the difference between a technology that has disappeared and one that has only moved out of sight.

Our own work at LILY is one attempt at Weiser's test: compiling an application into units smaller than a machine, so that deployment starts from the repository and the questions are about the application, not the hardware.

This part lead us to a harder question: If infrastructure should disappear, which parts of it are allowed to?

Fred Brooks drew that line in 1986, between the essence of a problem and its accidents. In the next part of this series, we will deal with this exact question.

Weiser ended his paper on a walk in the woods, coincidentally, Set and forget ended in the same manner. It may be where this argument leads, whichever way you walk in.

You build. We carry.

Start for free. Read the docs. Talk to us about migrating a workload.

Key sources

• Mark Weiser, Xerox PARC, The Computer for the 21st Century, Scientific American 265(3), September 1991
• Warren D. Devine Jr., Institute for Energy Analysis, From Shafts to Wires: Historical Perspective on Electrification, Journal of Economic History 43(2), June 1983
• Cloud Native Computing Foundation, Annual Cloud Native Survey 2025, 628 respondents, published January 2026
• LILY Labs, Set and forget, October 2026, and Billed Before the First Request, September 2026