We first published a version of this in November 2020. It was, in hindsight, half an argument dressed as a whole one, and it was written about a single provider. This is the piece rewritten: the same idea, taken further, and taken across all three.
A career can start with a fork. Mine started with a choice between Windows NT and Unix administration.
The Unix shell won, and the reason was not technical superiority. It was the feeling of the thing. Windows was a window: you looked through it at the machine. The shell was a door. The abstraction over compute, storage and network did not stand between you and the system, it gave you a way to reach in and move things. That distinction has shaped everything I have thought about infrastructure since.
BSD came next, then Linux, and a job that amounted to externalising computing power for people, quickly. Those units of compute started to interconnect. Power went up. So did complexity. Orchestration stopped being a nicety.
The line everyone half remembers
The network is the computer.
That was John Gage at Sun Microsystems, in 1984. It is one of the most quoted lines in the industry and one of the most misattributed, ours included: the version we published in 2020 credited John Cage, who was a composer, and who as far as we know had no opinion on distributed systems. Worth correcting, because the difference between a good slogan and a good idea is whether anyone checks it.
Gage was right about four decades early. What he described took until the late 2000s to become buyable.
Pets, cattle, and the thing that actually changed
Before that, we scaled by adding machines and hoping. Web servers spread across several boxes and were made to co-operate. Configuration management, Puppet and its relatives, declared a desired state and pushed systems towards it.
But the systems were still pets. Named, hand-fed, individually irreplaceable, each carrying some local modification nobody documented. The pets-and-cattle framing is usually credited to Bill Baker, then at Microsoft, and was popularised by Randy Bias. Our 2020 version attributed it to Adrian Cockcroft, who did a great deal to spread the practice but did not originate the phrase. Same correction, same reason.
Cattle was the real shift, and it was cultural before it was technical. A machine you are willing to destroy is a machine you have automated. A machine you are not, isn’t.
The App Engine lesson, which everyone repeats anyway
Google App Engine launched on 7 April 2008 and was, conceptually, exactly right. Consistent management of code. No fragility. No snowflakes.
It also asked you to write your software its way. The constraints were real, and no CFO was going to fund refactoring a working application to fit somebody’s platform. Adoption stalled, not because the idea was wrong, but because the price of entry was paid in rewrites.
That lesson keeps recurring. Every platform that demands your architecture conform before it will help you is selling you the same trade, and mostly losing the same argument. The things that won, on all three clouds, met people where their code already was: virtual machines first, then containers, then managed runtimes that accept an ordinary application.
Where the 2020 piece was too narrow
We wrote that essay about Google Cloud, because that is where our team’s instincts were formed. Reading it back, the provider was the least interesting part.
The idea was that a cloud is an operating system for the internet: a kernel you do not see, primitives you compose, and a shell to drive them. That is not a Google observation. All three hyperscalers arrived at the same shape, from different directions, and the shape is the point.
Different names, same nouns. Once you see the table, arguments about which cloud is best start to sound like arguments about which shell prompt is best. Occasionally interesting, rarely decisive.
What we got wrong about the shell
Here is the part the 2020 piece missed entirely.
We said the command line was the modern equivalent of the Unix shell: the place you reach in and move things. That was already becoming false as we wrote it.
The real shell turned out to be declarative. Not a person typing commands, but a description of the desired state, held in version control, applied by a machine, reconciled continuously. Terraform, and the Kubernetes control loop, and the pipeline that runs them. The interactive command line is now mostly for looking, not for doing. If you are changing production by typing, you have a pet.
The operating system metaphor survives this. It just relocates. The kernel is the provider’s control plane. The shell is your infrastructure code. The process table is your reconciliation loop. And the thing an operating system was always for, letting you stop thinking about the layer below, still holds.
The honest part about multi-cloud
The table above makes the clouds look interchangeable. In practice they are not, and anyone who tells you otherwise has not migrated anything.
What transfers cleanly is the shape: containers, object storage, identity boundaries, declared state. What does not transfer is everything that made the platform worth using. Managed databases behave differently under failure. Networking models differ in ways that only surface at the worst moment. Identity is where the real lock-in lives, because it is the thing every other service depends on. And egress pricing exists to make the question expensive.
So the useful position is neither “pick one and marry it” nor “abstract everything so you can leave”. Both are expensive. The workable one is to know which parts of your estate are commodity and which are deliberately provider-specific, and to be honest with yourself about which is which. Portability is a property you pay for. Sometimes it is worth the money. Often the better trade is to go deep on one platform and keep the seams documented.
We have run estates that span more than one cloud, not because it was elegant, but because that is where the systems actually were. Device fleets on one, services on another, joined in the middle. That is the normal condition of a business that has been buying technology for twenty years.
Why the idea still matters
The reason the operating system framing is worth keeping is not nostalgia. It is that it tells you where to put your attention.
An operating system is judged on what it lets you stop caring about. Nobody praises a kernel for its scheduler; they praise it by not thinking about scheduling. The clouds are the same. The value is not the service list. It is the set of problems you no longer have to solve, and the speed at which a small team can therefore do something ambitious.
That was the real argument in 2020, and it was buried under a provider name. A team our size can build and run national platforms because the layer beneath us is somebody else’s problem, deliberately chosen, and understood well enough to know exactly where it will let us down.
The door is still open. It just has a state file now.