Ship It Weekly Host Commentaries

Episode 2 is the “Kubernetes is growing up” episode.

It’s three themes that all connect if you’re on a platform team: old defaults are getting retired, platform engineering is turning into an actual discipline instead of a vibe, and AI is starting to become a first-class workload you’ll need to run and support.

First up, Ingress NGINX. Kubernetes is officially retiring it and moving it into best-effort maintenance until March 2026. If you’re still using it, this isn’t “panic today,” but it is a real clock. You need a plan, you need time for testing, and you need a way to migrate without turning your ingress layer into a random mix of controllers and annotations nobody understands.

The bigger point: core building blocks do get sunset. The earlier you treat “platform dependencies” like real dependencies, the less painful these transitions are.

Second, platform engineering. CNCF has been putting more shape around what it actually means, and I like that the conversation is moving past buzzwords. Platform as a product sounds corny until you realize it’s basically: internal customers, a roadmap, docs that don’t suck, paved paths, and feedback loops. Plus the Kubernetes lessons learned piece is full of the usual hard-earned truths… operational consistency beats cleverness, and the clusters that hurt the most are usually the ones that grew “organically” for years without guardrails.

Third, AI on Kubernetes and “AI-native SRE.” CNCF’s new AI Conformance program is a big signal. AI workloads are not just another stateless web app. They’re heavier, they’re weirder, and they care about things like GPU scheduling, data locality, and reproducibility. And on the SRE side, the “systems learn and drift” angle is real. Reliability isn’t only “is it up.” It’s also “is it behaving the same way it did last week.” If you’re responsible for operating AI-powered systems, you’re going to end up caring about model versions, data changes, and guardrails as much as you care about CPU and memory.

Then in the lightning round we hit a few great reads on zero-downtime database work, Postgres upgrades, and a Kafka priority queue, and we close with the human side of incidents: fixation during response and how incidents become landmarks for the tradeoffs you’ve been making over time.

If episode 1 was “the cloud is a dependency graph,” episode 2 is “your platform is a product, whether you admit it or not.”

Show notes below have all the links if you want to dig into the source posts.

Episode 1 is a special, and it’s basically the reason Ship It Weekly exists.

When outages hit, most write-ups stop at “service X was down for Y minutes.” That’s useful, but it doesn’t help you answer the real question you get asked at work: “Could this happen to us, and what would we do?”

So this episode is a tour through three separate “cloud had a bad day” moments:

Cloudflare, AWS us-east-1, and GitHub.

Not to dunk on any of them. These companies run infrastructure at a scale most of us will never touch. The point is the pattern: even well-designed systems fail, and the failure modes are rarely the ones you expect on paper.

As you listen, I’d keep a few platform-team questions in mind:

If our CDN or DNS provider is having a rough day, do we have a fallback? Even if it’s not “multi-CDN,” do we have a clear story for what degrades gracefully vs what hard-fails?

If us-east-1 gets weird, what’s our real blast radius? Are we truly multi-region, or are we “multi-region in PowerPoint” but still dependent on a single region for identity, DNS, CI, or some shared data layer?

If GitHub is down, can we still ship? Not “can devs still code,” but can we deploy, roll back, or run emergency changes without our normal pipeline?

This is also a good example of why I don’t love the phrase “the cloud is someone else’s computer.” The cloud is a stack of dependencies, and you’re still accountable for how you consume it. The job isn’t to eliminate outages. The job is to design your systems and your runbooks so an upstream outage doesn’t turn into a full business outage.

If you’re the person people ping when prod is weird, you’re going to recognize the vibe of this episode.

And if you’re building a platform team, this is a nice reminder that “reliability work” isn’t just SLO dashboards. It’s dependency mapping, recovery plans, and making sure you have a sane break-glass path when your normal tools are unavailable.

If you want to go deeper, check the show notes below. I included the incident links and the official write-ups so you can cross-reference the details.