10 Years of Distributed Computing with Kubernetes

Ground Zero: Open Source Conference North America 2015

On July 2, 2015, in a packed room at OSCON, we cut the ribbon on Kubernetes 1.0. I was the first PM who didn't sign the founding doc, yet I got the privilege of wiring the detonator that became Google Kubernetes Engine (née "Container Engine"). The last decade of distributed computing unfolded from that single push to GitHub.

As an aside, we kept deploying WordPress all the time. I'll never understand why we thought that was the killer scenario. But we did. Actually, the first killer scenario was the scale-up for Pokémon GO. Here I am talking about it just a few weeks later.

Success, in Four Bullet Points

Looking back, four early choices carried Kubernetes from "interesting side project running on Brendan Burns' laptop and a go project named 'Seven'" to the default substrate of cloud-native computing.

• Portability
• What We Did: Write once, run anywhere … actually anywhere.
• Why It Mattered: Decoupling workloads from hardware and vendor lock-in flipped the power dynamic from cloud providers to developers.
• Containers over Code
• What We Did: We orchestrated containers, not application code.
• Why It Mattered: By riding Docker's wave instead of trying to replace it, we let the community package apps however they wanted and focused on making them run.
• Scale as a Primitive
• What We Did: Consensus-driven scaling baked into the control plane.
• Why It Mattered: "Throw more nodes at it" stopped being a Big-Tech luxury and became a one-liner for everyone else.
• Flat Networking
• What We Did: Every Pod gets an IP, full stop.
• Why It Mattered: Simple mental model, zero overlay voodoo. Devs could think about services, not subnets.

Gap Left Unaddressed: Distributed Data

Kubernetes tamed stateless compute, but data stayed glued to gravity wells: - StatefulSets help keep a few disks alive, but they're not a data platform, and they are definitely not unified. - Operators/Helm/Kustomize - they help! But they make Day-2 HARD and, similarly, they leave working on things together as an exercise to the reader. - "Just migrate to a warehouse first" burns time, money, and often security & compliance.

Distributed compute without distributed data is a half-solved equation. The future isn't a single mega-warehouse; it's globally-aware jobs running where the data already lives.

That gap is why we founded Expanso. Our mission: make running data-intensive workloads WHERE THE DATA ALREADY LIVES as boring as running kubectl apply. No duct tape pipelines, no overnight rsync marathons, no guessing which hemisphere your GDPR bits landed in.

What Comes Next

1. Declarative Data Workflows — Treat data placement like we treat Pod scheduling: describe intent, let the system schedule reality.
2. Edge-Native Analytics — Push compute to the edge so you don't drag petabytes back to the core.
3. Built-in Governance — Location-aware, policy-enforced from the first byte, not after the compliance team discovers a rogue S3 bucket.
4. Zero-Drama Migration — Migrate workloads (and their data) the way we migrate Pods today: seamlessly, without a migration weekend.

Call to Action

If you're sick of stitching together pipelines that hop continents before delivering value, let's talk. The next decade demands a data layer that's as ubiquitous and invisible as kube-scheduler.

Flashback: If you want a nostalgia hit, here's the original launch-party post from 2015. It's a reminder that every "overnight success" starts with a roomful of skeptics.

To Craig McLuckie, Brendan Burns, Kit Merker, and every engineer who hit "approve" on that first PR: thank you for the ride. Now let's finish the job.

Series RoadmapThis piece kicks off a series examining Kubernetes at ten: where it's excelled, where it's stalled, and how we bridge compute and data in a truly distributed world. Next up: tracing the journey from humble container orchestrator to the sprawling cloud-native ecosystem we rely on today.