Was reading "Jurassic Cloud" recently: one of those systems papers that starts with I/O performance and ends up dismantling everything you thought you knew about how computers work.
tl;dr: the hardware changed, the software didn't keep up, and now we're running modern workloads on design assumptions from 2001.
RAM used to be 1000x faster than disk, so of course it would make sense to cache everything in memory. Except now NVMe drives have microsecond latency, network bandwidth increased 1000x, and RAM … barely improved. We're still copying data through RAM like it's precious and fast, when it's actually become the constraint.
The Linux I/O model (the page cache, the blocking API, the whole "everything is a file" abstraction) was architected for 10ms spinning disks. Context switches that cost 1-5 microseconds were negligible compared to that. Now, with 10µs NVMe reads, those same context switches are catastrophically expensive. You're paying more for the coordination overhead than for the actual I/O.
I'm sure anyone who works long enough with large enough systems, can relate to this pattern, even if you don't know the nitty-gritty of database internals. You optimize for one set of constraints, the constraints change underneath you, and suddenly your entire architecture is fighting against reality instead of working with it … or as the article puts it: "core design assumptions have been voided".
The proposed solutions
The author worked (this paper is 3 years old now) at ScyllaDB, so predictably, the solution was "bypass the kernel entirely."
Their Seastar framework treats each CPU core as an independent computer, communicates via explicit messages, manages its own I/O scheduler. Essentially: if your machine is already a distributed system (which it is, with 100+ cores all fighting for shared resources), just admit it and design accordingly.
However, a lot seems to have happened since the article was written in 2022:
The kernel fought back. io_uring (which the article mentions briefly) is now mainstream. It's a proper async I/O interface that lets you submit thousands of operations with a single syscall. Postgres uses it. Web servers use it. It solves 90% of the problem without forcing you to rewrite everything.
And then there's eBPF, which the article completely missed. Instead of bypassing the kernel or waiting for kernel developers to add features, you can now run safe, sandboxed code inside the kernel. Want custom networking logic or better observability? Write an eBPF program. It's become the dominant "middle path": you're not locked into POSIX, but you're not rebuilding the world from scratch either.
The hardware trend is accelerating too. CXL (Compute Express Link) is making memory and storage "disaggregated": CPUs can access remote memory pools, storage can bypass the main CPU entirely. The "distributed system in a box" thesis is happening faster than predicted.
What this means (or doesn't)
For me? Probably nothing immediate. I'm not building databases or writing kernel code (right now!). But the patternmatters: when your foundational abstractions lag too far behind reality, everything built on top inherits that technical debt. Every framework, every optimization, every "best practice" is working around problems that shouldn't exist in the first place.
Looking at the 2025 landscape though, there's no single answer. You've got:
- Kernel bypass (Seastar/SPDK): maximum performance, maximum complexity
- Better kernel (io_uring): native solution, pretty fast, way less work
- Programmable kernel (eBPF): flexible middle ground, taking over cloud-native
Which matters more than the specific solution is the acknowledgment that the old model is broken.
Your services are mysteriously slow, your costs are weirdly high, and the "best practices" from five years ago don't work anymore … Maybe it's not your code. Maybe it's the 30-year-old I/O model underneath everything :-)
The author ends with a call for revolution, which... sure. More realistically, we're getting incremental renovation: io_uring and eBPF are proof the kernel can evolve. But the Jurassic foundations are still there, and they're still cracking.
(As always, read the original if you want the full technical depth, I'm just documenting what caught my attention and why it seemed worth sharing.)