DEV Community: Elias Goldbach

LILY Margin Notes, part 1: The technologies that disappear

Elias Goldbach — Tue, 03 Nov 2026 15:37:00 +0000

A technology has reached maturity when people stop noticing it. Writing passed that test shortly after Gutenberg's reimagining of the printing 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 think about, a circumstance we deem unacceptable.

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 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 led 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

Originally published on lilylabs.io.

Set and forget

Elias Goldbach — Thu, 15 Oct 2026 16:37:53 +0000

Every leap in computing has handed people back a piece of their time by taking one job off their hands. Keeping your application alive after it is written, is the next one to go.

An essay from LILY Labs

The history of computing can be told as a list of jobs that stopped being jobs.

In 1957, John Backus and his team at IBM released FORTRAN, and programmers stopped writing most of their instructions in the language of the machine. They described the calculation, and a compiler worked out the rest. Around 1960, John McCarthy, at MIT, built automatic memory management into Lisp. A whole category of bookkeeping, deciding when each piece of memory could be given back, moved from the programmer to the system. In 2006, Amazon put storage on sale at fifteen cents a gigabyte-month. Now a company could stop buying and managing their own hard drives and keep access to their data anyway.

Each time, people worried that something important was being lost. Each time, the people freed from the job did not sit idle. They built more interesting things on top.

None of these transitions was clean. Compilers produced slow code for years. Garbage collection brought pauses of its own. The cloud swapped buying machines for configuring them. Every handover created some new work alongside the work it removed. But the direction stayed steady. A job that used to fill a day became a thing the system took over automatically.

Writing code has never been faster. Tools that help with it, many of them now built on AI, can produce in an afternoon what used to take a week. The odd thing is how little that has changed the rest of the week.

Writing out the application logic is only one step. After it is written, someone has to package it, choose a machine for it, decide how many copies to run, set rules for when to add more, watch it, patch what sits beneath it, and answer the phone when any of that goes wrong. None of those tasks got meaningfully faster while the output of code exploded.

Komodor, a vendor for Kubernetes troubleshooting tools, reported in its 2025 Enterprise Kubernetes Report that operations teams spend more than 60 percent of their time troubleshooting. Even if discounted by a large margin, that is still a sizeable number. The bottleneck has moved. It used to be in the creation of software. Increasingly it lies in keeping that same software running.

The one-person organization

AI writes the code. Payments, email and sign-in arrive as services. Set and forget takes the servers off the list. Stack those together and one person can do what took a small team a few years ago: build a product, ship it, and keep it running.

And it is leaving the screen. CNC mills, 3D printers and laser cutters now fit in a spare room, and AI can walk a beginner from the first sketch to the finished part. Someone tired of a bike part that keeps breaking can design a better one over a weekend, print three prototypes, mill the final version in aluminium and be selling it a month later. The shop, the order queue and the shipping emails are just software. Set it once, and the attention goes back to the product.

Just open YouTube, the creator economy has exploded with people building things on their own that used to need a workshop and a team: electric conversions in home garages, hand-built instruments, hardware products shipped worldwide, and courses teaching everyone else to do the same. That flood of content is a public record of the new tools at work.

A product for a few hundred customers becomes a real business when all of them can be operated from a single hand. An idea can be tested within a week, not after a funding round. And the most valuable skills shift from depth to range: knowing enough about design, materials, code and customers to connect them, and to spot when the AI is wrong. Deciding what to build is still the hard part. Everything around it is getting lighter.

The freed hours can go in two directions:

The first is to do more. One person directs a small organization of agents, each carrying part of the work: E.g. one writes code, one answers customers, one watches the stock, one drafts the next product page. The person in the middle decides, checks and connects as the central orchestrating node in this network of agents.

The second is quite the opposite: Much of a working day is not work at all. It is clutter: searching five internal tools for one document, filling in the same fields on a contract for the tenth time, photographing a flat and clicking through every menu it takes to list it for rent. Each step is a tiny decision: the click of a button, locating the next textbox to fill out, remembering which note taking tool holds a specific piece of information, etc., etc. Together they can eat hours in front of a screen. That is exactly the kind of work agents are good at. The human in the loop simply needs to track the outputs to deliver. A lot of the workflows, machines can now take over just as well as an actual personal assistant, freeing up the users time.

Most people will mix the two. For decades, software competed for attention: more features, more dashboards, more reasons to log in. The tools that win next may be the ones that ask for the least of it. A product that does its job while nobody is looking stops being one more thing to manage and becomes what infrastructure was always supposed to be: the part underneath that lets everything else happen.

Back in the forest

It would be easy to end on productivity. Ship faster, do more, fill the freed hours with more of the same.

That is not quite the point. The people who stopped writing machine code did not spend the time writing more machine code. They spent it on problems that had been out of reach.

There is a catch. Agents shorten the loop between decisions. A change that once took a week to build now comes back in an hour and asks for the next call straight away. The manual work that used to sit between choices, and quietly gave the mind a rest, is disappearing. What is left is a day made almost entirely of decisions, and decision fatigue grows with it.

The same shift also loosens where work happens. You can walk through a park with a pair of smart glasses, talking an agent through a rewrite of your backend. Some of the freed time should go to nothing at all. Time, to replenish the cognitive resources spent. Deploy with us and rest easy, we will take care of the rest!

You build. We carry.

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

Originally published on lilylabs.io.

European Infrastructure is having a Moment

Elias Goldbach — Thu, 03 Sep 2026 16:08:29 +0000

While the demand for compute is blowing up, the supply side hasn't caught up. That gap is the entire opportunity.

Something has started to shift in the European cloud space. It is not arriving in the form of launches, It is arriving in the form of experiments.

Providers that spent a decade selling machines, bandwidth and storage are beginning to reach up the stack: Managed runtimes, hosted inference, exactly the layers where the value has moved. Early attempts mostly mostly boil down to a model or two, no billing, no SLA and no promises about behavior under load. Put out to find out whether anyone wants the thing at all.

The products are minor. The reaction to them is not.

Each release refuels an ongoing debate on forums like Hacker News and Reddit. Engineers talk to each other candidly, and the argument is never really about the product. It is about whether Europe even has the capacity, to build this layer at all.

Two things surface every time, and they sit awkwardly together.

Europe has providers. It does not have a contender.

There is no shortage of European companies operating at this layer. National ones, regional ones, telco-backed, retail-conglomerate-backed. There have been new entrants arriving for a decade. What Europe does not have is a product an engineer would choose purely based on its merits. The jurisdiction should be treated as a bonus rather than the justification. Currently, all of the options at this layer that actually win on capability, tooling, throughput and reliability is built somewhere else.

That is the real gap, and it is a technical one. Not a shortage of providers. Not a shortage of demand, as we will get to. A shortage of maturity: infrastructure that holds up under production load, ships the features that make workloads economical, and would survive the day the compliance requirement expires.

Note what that implies. Entrants have existed for years and none of them has closed the distance, so the problem is not effort and it is not absence. It is approach.

It also explains why the sovereignty markup lands as an insult rather than a trade-off. Paying more is defensible when you get something for it. Paying more for less, and being asked to call it a principle, is not.

One developer summarised the bind: hard to make the regulatory gods (and the devs) happy at the same time.

Read the parenthesis. Compliance and engineering are treated as two separate constituencies, satisfied separately, and European infrastructure is widely assumed to be incapable of satisfying both at once. That is not an outsider's critique of the category. It is how the category's own buyers describe it to each other when no vendor is in the room.

The demand side has already moved

The appetite is not in doubt anymore, and it is no longer expressed in position papers. It is expressed in procurement.

Roughly six in ten Western European CIOs say they intend to increase their use of local cloud providers.

The legislative machinery has moved with it. The EU Cloud and AI Development Act, proposed on 3 June 2026 as the centerpiece of the Tech Sovereignty Package, would introduce four graduated assurance levels governing which providers can serve the public sector and critical infrastructure. On 25 June 2026 the Commission reached a preliminary position that the two largest cloud services in the EU should be designated as gatekeepers under the Digital Markets Act — the first time the law has been pointed at infrastructure rather than consumer platforms, on grounds of lock-in and switching costs.

And yet. European providers still only hold around 15% of their own regional market, a figure that has been flat since 2022 while the market itself grew roughly sixfold. The hyperscalers hold about 70%.

Sentiment moved. Spend didn't. Which tells you the constraint is not political will, and never was. The constraint is product.

Residency was never the argument

The reason data residency stopped being persuasive has a date on it.

On 10 June 2025, a hyperscaler's French legal director was asked before a Senate inquiry, under oath, whether he could guarantee that French citizens' data would never be transmitted to US authorities without French approval. His answer was "No, I cannot guarantee that", adding, that it had never happened so far.

Nothing had failed. The EU regions existed. The encryption existed. The EU-resident staff existed. The certifications were all in order. None of it was relevant to the question, because the question was about jurisdiction, and jurisdiction sits upstream of every control a provider can implement.

This is the distinction that matters, and it is worth stating plainly:

A certification describes how a provider behaves. Jurisdiction determines who can compel it to behave differently.

You can buy the first. It is a process, an audit, a renewable badge. You cannot buy the second. It is a fact about where a company is incorporated, who ultimately owns it, and which courts can reach its officers. No amount of architecture converts one into the other.

The interesting thing about the Cloud and AI Development Act is that it concedes exactly this. The lower assurance levels are satisfiable through localisation and process, which is why EU subsidiaries of foreign providers largely qualify. The higher levels turn on ownership, control, and demonstrated independence from third-country influence.

The sovereignty markup is the real risk

The objection, that you pay a premium for a worse product, is the one worth taking seriously, because it is the failure mode that would waste this entire moment.

If European infrastructure sells only because a regulation obliges someone to buy it, then it is a tax with a flag on it. Products built for that market get built for auditors. They win the tender and lose the developer, and the developer is the one who decides whether the contract gets renewed in three years. While procurement can create a floor, in addition to the high electricity prices, do European companies really need a second basic utility shooting up in price to the point where that creates negative pressure on their international competitiveness?

Europe built its own car industry. It did not do it by asking Europeans to buy worse cars for patriotic reasons. It did it by building cars people wanted, that happened to be built here. The cloud is overdue for the same thing.

Four questions worth asking instead

If you are deciding where compute should live, the useful questions are not about badges.

Who owns the entity, and whose courts can compel it? Not where the servers are. Not where the support team sits. Ask in writing, and keep the answer.
What happens to the workload if a jurisdiction changes its mind? Sanctions, export controls, and licence terms are faster to change than architecture is.
Am I paying a premium for jurisdiction, or is jurisdiction a property of something that is better anyway? If the answer is the first one, the decision will be reversed by whoever inherits the budget.
Could I leave? Egress economics and interoperability are the actual measure of independence. Everything else is a preference.

Where we sit

The reason to think a European entrant can compete is not that it will match hyperscaler capital expenditure. It won't; roughly €10 billion a quarter goes into European capex from the incumbents alone. Matching that is not a strategy.

The way through is product. European infrastructure has to win by making deployment feel simpler, cheaper to operate, and easier to trust — not by asking developers to accept a weaker experience for jurisdictional reasons.

That is where LILY comes into play: a European cloud platform designed around a smaller operational surface. The point is not to publish the machinery. The point is that a developer should be able to connect a repository, configure the application, and run it without owning the layers that usually sit between code and production. The jurisdiction is a fact about where we are incorporated and where the machines are. It is not the reason to use us.

The moment is real, and it is currently a demand-side moment. Whether "European cloud" ends up meaning a procurement category or a technical one is still open. Making the regulatory gods and the developers happy at the same time is not a law of nature. It is a product gap.

We are building for the second reading.

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

Europe has no shortage of cloud providers. What it does not have is one an engineer would choose on merit, with the jurisdiction as a bonus rather than the justification.