The history of servers, the cloud, and what’s next

The Pragmatic Engineer

The history of servers, the cloud, and what’s next – with Oxide

0:00

-1:39:16

The history of servers, the cloud, and what’s next – with Oxide

Bryan Cantrill explains how decades of server and cloud evolution shaped modern infrastructure and what today's software engineers can learn from it.

Gergely Orosz

Dec 17, 2025

Stream the latest episode

Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.

Brought to You by

•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Companies like Meta and Google had to build their own infrastructure for safer deployments and experimentation. Statsig makes this advanced tooling accessible to everyone. They have a generous free tier, a $50K startup program, and affordable enterprise plans. Check it out.

•⁠ Linear ⁠ — ⁠ The system for modern product development. We know that AI will be part of the software stack — in fact, it already is, today. To support AI agents, Linear they built an open API and SDK that lets any agent plug into your issue tracker. You can also connect popular agents like ike Cursor, GitHub Copilot, OpenAI Codex, and others. Take a look at how Linear works with agents.

In this episode

How have servers and the cloud evolved in the last 30 years, and what might be next? Bryan Cantrill was a distinguished engineer at Sun Microsystems during both the Dotcom Boom and the Dotcom Bust. Today, he is the co-founder and CTO of Oxide Computer, where he works on modern server infrastructure.

In this episode of The Pragmatic Engineer, Bryan joins me to break down how modern computing infrastructure evolved. We discuss why the Dotcom Bust produced deeper innovation than the Boom, how constraints shape better systems, and what the rise of the cloud changed and did not change about building reliable infrastructure.

Our conversation covers early web infrastructure at Sun, the emergence of AWS, Kubernetes and cloud neutrality, and the tradeoffs between renting cloud space and building your own. We also touch on the complexity of server-side software updates, experimenting with AI, the limits of large language models, and how engineering organizations scale without losing their values.

If you want a systems-level perspective on computing that connects past cycles to today’s engineering decisions, this episode offers a rare long-range view.

Interesting sections from the episode

How the “Dotcom Bust” brought more tech creativity than the “Boom.” As Bryan recalled (starting at 14:53), memories from the Dotcom Boom and Bust:

“A boom can get you to care about things that you actually don’t care about. This is because in a boom, everyone is so financially driven that it’s hard not to become financially driven!
But [the financial side] is actually not why I got into this. So during the bust, I was definitely able to put a meal on my table and a roof over my head. But [the Bust] was a reminder about what’s important.
We did better technical work in the Bust than in the Boom. I think that’s because in the Bust it was like: okay, now we really have to focus. We have fewer resources. These fewer resources actually force more creativity!
So all of the things that we did, certainly speaking at Sun and system software, so ZFS filesystem] and DTrace [dynamic tracing framework] and Service Manager Facility [unified service management framework in Solaris 10], all these things that were really revolutionary for the operating system. All of these [innovations] happened in this same kind of post-Bust period of time, from 2001 to 2005.”

How Jeff Bezos tricked everyone with AWS pricing. Bryan was running a small competitor to AWS called Joyent, and so he knew something about AWS pricing that the rest of the world was yet to catch up to (starting at 26:07)

“Jeff Bezos is the apex predator of camitalism.
The thing that was so impressive is they were able to give people the idea that this [AWS] was a terrible business. In particular, they did not break out their financials. So everyone’s like: 'oh my God, what an awful business! They’re [AWS is] cutting the price every year. This is a classic ‘red ocean’. It’s bloody, you don’t want to compete.
At Joyent, we were actually competing head to head with AWS. We had a public cloud. And unlike AWS, we took the software that we had used to run the public cloud and made it available for people that wanted to run a cloud on-prem on their own hardware. So people that would buy Dell or HP or Super Micro, they would buy [Joyent’s] software and they would run it and get a cloud.
So we ran a public cloud and we knew what the economics of a public cloud were, namely pretty good. Margins were good! And so what we knew that Amazon wasn’t volunteering [the price cuts.]
We knew is that AWS S3 was underwriting a war on big box retail, and that S3 was paying for your Prime shipping!
So it was a genius move [by Bezos.]”

Why Kubernetes might have become really popular, in part thanks to AWS. Bryan, starting at 27:42:

“There was a period of time when it felt like in order to be in the cloud [business] you have to implement every AWS API [as a cloud provider]. So there’s this idea that you had to be [fully] compatible with EC2. One reason it was thought that GCP and Azure could never compete with AWS was because they could never be API compatible.
Then, what starts in 2015 is Kubernetes. Part of that initial attraction to Kubernetes is that people wanted to get some optionality around their cloud — and they felt locked into AWS. They’re like ‘I’m not using all this stuff [on AWS]. I’m not using Elastic Beanstalk [PaaS for web applications]. I’m not using IoT Greenglass [edge runtime and cloud for IoT services]. I’m not using Redshift [SQL-based cloud data warehouse]. What I actually want is this kind of basic infrastructure.
Kubernetes now gives me this layer upon which I can deploy and get some sort of true cloud neutrality. The early momentum behind Kubernetes [felt like] this around this idea of I need to have some optionality [from AWS].”

Interesting: Oxide found it hard to hire hardware engineers who are principles-first, and folks who can build hardware without a “reference design” available. Turns out, building a new type of computer like Oxide means creating hardware from scratch, instead of using “reference designs.” Many hardware engineers are simply not used to doing this:

Bryan: “In computer [hardware] design in particular, the high-speed designs are so hard that [electrical engineers] got very accustomed to taking the reference designs. And it was harder to find folks who were willing to take a clean sheet of paper. Ultimately, we found them, and we’ve got an EE (electrical engineering) team that is extraordinary and absolutely fearless.
[The EE engineers at Oxide] didn’t spend their careers at Dell and HPE. They’re coming from [the likes of] GE Medical where they worked on CT systems.
Gergely: “It feels like such a different field. I would naively assume that if you’re building a computer, you’ll try to get electronics engineers who have built computers.
Bryan: “You would think! That was our [initial] thought as well. Then we discovered that we were not getting along with those engineers very well.
We were just finding there’s a lot of friction because there wasn’t a real first-principles approach. When you get to talk to folks that have been at Dell for a generation, for any design, they’re used to calling what’s called the FAE. FAE stands for the Field Applications Engineer for the voltage regulator. It’s like: ‘well the FAE gives me the design.’ So we ask: ‘Alright, well how do you know that it’s the right design?’ So we went, alright, so let’s go hire that person [who understands the actual design.]”

Bryan initially struggled to find the “right” electrical engineers — until Bryan shared in an article that they paid everyone at Oxide a $175,000 base salary in 2021 (today, this number is $235,000 today.) This article got shared inside hardware engineering circles, and suddenly they got standout electrical engineers applying — who often have not built computers before, but have been designing electrical equipmen and hardware from zero in other fields.