Ship It Weekly Host Commentaries

For Episode 8, I wanted to stay on the “platform reality” side of the internet: scaling constraints, governance you can’t dodge, and the blast radius of “easy buttons.”

First story is Cloudflare’s internal maintenance scheduler on Workers. I like this write-up because it’s not “serverless is magic,” it’s the stuff you actually hit when you build internal platform tooling: memory limits, request fanout limits, and the classic mistake of pulling giant datasets into a runtime just so you can throw most of it away. The part worth stealing is their shift from “load everything and compute” to “query the dependency neighborhood that matters,” with caching and deduping to keep request counts sane. Also, the Parquet angle is underrated: historical analysis tends to rot into slow object storage thrash unless you intentionally design for it.

Cloudflare post:
https://blog.cloudflare.com/building-our-maintenance-scheduler-on-workers/

Second story is AWS databases showing up inside the Vercel Marketplace. This is a quiet shift with loud consequences. The dev experience is great: click-button a real AWS database from the same place you deploy your app. The platform team experience is… now your app platform is also provisioning cloud resources, which means you need a governance story that meets developers where they are.

A few extra things I didn’t go deep on in the episode, but you should think about if you run platform/cloud governance:

Account sprawl: if this creates new AWS accounts (especially outside your AWS Organization), you’ll end up with “unknown unknowns” fast.

Cost ownership: make sure there’s an enforced tagging/cost allocation baseline, budgets, and alarms. Otherwise this becomes the new shadow IT.

Networking posture: are these DBs public by default? Private? Do you want to mandate VPC-only connectivity for prod? What’s the migration path when a “quick dev DB” becomes a real production dependency?

IAM + audit trail: who’s allowed to provision? Who can delete? Do you have CloudTrail/logging/detection baselines in place for these resources?

Data residency/regions: easy UIs tend to hide region decisions. That matters for latency and compliance.

AWS announcement + Vercel changelog:
https://aws.amazon.com/about-aws/whats-new/2025/12/aws-databases-are-available-on-the-vercel/
https://vercel.com/changelog/aws-databases-now-available-on-the-vercel-marketplace

Third story is TEAM (Temporary Elevated Access Management) for IAM Identity Center. This is one of those “everyone says least privilege” areas where teams usually fail in practice, because the workflow is painful. TEAM is basically a reference implementation for what you actually want: request elevated access for a specific time window, approval workflow, auto-expiry, and auditing. Auto-expiry is the difference between “least privilege” and “permanent privilege creep.”

A couple extra thoughts here:

Break-glass vs daily elevation: break-glass should be rare, loud, and scary. Daily elevation should be controlled and boring. Don’t mix those.

Approval speed matters: if approvals are slow, engineers route around it. The process has to be fast enough that people keep using it.

Make the default roles boring: the whole point is that you don’t sit in admin all day. If everyone already has broad power, JIT becomes theater.

TEAM docs + repo (and AWS security blog post):
https://aws-samples.github.io/iam-identity-center-team/
https://github.com/aws-samples/iam-identity-center-team
https://aws.amazon.com/blogs/security/temporary-elevated-access-management-with-iam-identity-center/

Lightning round extras:

GitHub Actions workflows page performance improvements (this matters more than it sounds if you’re in Actions during incidents):
https://github.blog/changelog/2025-12-22-improved-performance-for-github-actions-workflows-page/

Lambda Managed Instances (Lambda-on-EC2-ish). The interesting bit is the “steady-state + specialized compute” positioning, plus the concurrency model shift where one execution environment can handle multiple requests. That means thread safety/shared state becomes your problem again.
Docs:
https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html

atmos issue list (for #1831 context):
https://github.com/cloudposse/atmos/issues

k8sdiagram.fun:
https://k8sdiagram.fun/

Human closer: Marc Brooker’s “What Now? Handling Errors in Large Systems.” This is the best “read it once and it changes how you think” link of the week. The big lesson is that error handling is architecture. Crashing vs retrying vs continuing only makes sense when you understand correlation, blast radius, and what “safe to continue” means in your system.
https://brooker.co.za/blog/2025/11/20/what-now.html

If you want to come on the show for a conversation episode, hit the email on shipitweekly.fm. I’m looking for people doing the work for real (platform, SRE, DevEx, cloud governance, migrations, incident scars… all of it).

Episode 7 is the first Ship It conversation episode, and it’s also a good time to explain what Ship It Weekly is turning into.

Most weeks, Ship It Weekly is a short news show. I skim the DevOps/SRE/platform headlines, pull out the stuff that actually matters, and give you the “ok cool… what does this mean for people running infra and owning reliability” version. It’s meant to be quick, useful, and easy to listen to while you’re doing something else.

But I also want to mix in conversations with engineers who are actually building and operating this stuff. The news format is great for breadth. Interviews are better for depth. You get the war stories, the why behind decisions, and the stuff that doesn’t fit into a 10–20 minute rundown.

So going forward you’ll see two types of episodes:

Ship It Weekly: the news recap and takeaways.
Ship It Interviews: longer, conversation-style episodes with guests.

Loose cadence wise, the idea is interviews earlier in the week and the news recap later in the week, but I’m not treating that as a hard rule. Some weeks will be all news, some weeks will be an interview plus a news episode, and sometimes we’ll do specials when something big happens. The goal is consistency and usefulness, not sticking to a rigid calendar.

For this first interview, I’m joined by Maz Islam. We talk about the real reason DevOps exists in the first place, what “upskilling” looks like when you’re already busy and tired, and how to think about agentic AI without getting lost in hype.

We also get into the practical side: where automation actually pays off, what habits and mental models help you level up faster, and how to avoid the trap of collecting tools without building real capability. It’s less “top 10 tools” and more “how do you actually get better and build leverage over time.”

If you’re early in your journey, this episode should give you direction and some momentum. If you’re already deep in the weeds, it’ll probably feel like a useful reset and a reminder of what’s worth focusing on when everything is changing at once.

Links and notes from the episode are below.

Episode 6 is a “platform tax” week.

Not because anything is fun and shiny, but because a bunch of the stuff that keeps your org shipping quietly changed shape at the same time: CI economics, IaC platform limits, and new security boundaries thanks to AI agents.

We start with GitHub Actions. GitHub floated a new charge for self-hosted runners, got immediate pushback, and then paused the change while they re-evaluate. The important part isn’t the drama. It’s the signal: Actions is a control plane, and GitHub is clearly thinking hard about how it gets priced. We also got the perfect timing joke with a GitHub incident the same week, which is a reminder that CI isn’t just “dev convenience.” For a lot of teams it’s the delivery pipeline, the GitOps loop, and the break-glass path… until it isn’t.

Then we shift to HashiCorp and Terraform Cloud. Legacy Free orgs are heading toward end-of-life in 2026, with transitions to the newer Free tier capped at 500 managed resources. That number is either totally fine or instantly painful depending on how real your infrastructure is. The practical takeaway is simple: know your resource count, clean up zombie stacks, and decide early whether you’re paying, consolidating, or migrating. Don’t make it a March 2026 emergency.

After that, we talk about PromptPwnd and the broader “AI in CI” problem. Teams are wiring agents into pipelines that read PRs and issues, and if you feed untrusted text into prompts while the agent has tools and tokens, you’ve created a new kind of supply chain risk. The fix is the same boring security posture we always preach: sanitize inputs, minimize permissions, and don’t let an agent auto-execute anything just because it sounds confident.

We also touch a classic security hygiene story around long-lived access exposure as a reminder that secrets, blast radius, and detection still matter more than whatever new automation you just bolted on.

Lightning round hits CDKTF being sunset/archived, Bitbucket cleaning up free unused workspaces, and SourceHut’s proposed pricing changes as more evidence that tooling economics are shifting everywhere.

This episode is basically a reminder that platform engineering isn’t only Kubernetes and Terraform. It’s also vendor models, dependency planning, and making sure your pipelines don’t turn into single points of failure.

Show notes below have the links if you want to dig into the announcements and write-ups.

Episode 5 is one of those weeks where the headlines hit three totally different layers of the stack… but they all land on the same people: the folks responsible for keeping systems safe, stable, and shippable.

We start with IBM buying Confluent. Coming right after the HashiCorp deal, it’s a pretty loud signal about where IBM is going: control plane plus data plane, all aimed at enterprise AI and “smart infrastructure.” If you’re on Confluent Cloud or evaluating it, the real question isn’t “is Confluent good.” It’s “what’s our vendor concentration story, and do we have a plan B if packaging, pricing, or priorities shift post-acquisition.”

Then we move to React2Shell, a critical RCE in React Server Components that’s already being exploited in the wild. Even if you’ve never written a line of React, this matters if you run Kubernetes or platforms for teams building modern web apps. It’s server-side code execution. That means patch windows, WAF/rule coverage, and making sure the blast radius of a compromised app pod isn’t “cool, now they own the cluster.”

Third, Netflix’s Aurora write-up. They consolidated a chunk of their relational database fleet onto Aurora PostgreSQL and reported big performance improvements plus meaningful cost savings. The interesting part isn’t “Aurora is magic.” It’s the reminder that self-managed database fleets quietly become an ops tax over time, and sometimes the grown-up move is standardizing on a managed path so you can spend your energy on the parts that actually differentiate your product.

Lightning round is a mix of tools and ecosystem signals: OpenTofu 1.11 shipping new language features, a practical Terraform “tips from the trenches” post, Ghostty moving under a non-profit model, and a quick look at spec-driven development with AI (Spec Kit and OpenSpec) as a saner alternative to free-form “let the agent do whatever.”

We close with a human note: incidents, vendor changes, and security fire drills all land on the same small set of people. The tech is one thing, but the mental load is real, and platform work increasingly includes managing that constant drip of surprise.

Show notes below have all the links if you want to go deeper on the acquisition, the vuln details, and the Netflix architecture story.

Episode 4 is my “big platforms week” episode.

We start with AWS re:Invent, but not in the usual hypey way. I’m looking at it like a platform team would: what changes the paved roads, what changes the reliability story, and what’s going to show up as a ticket in your queue three months from now.

That includes stuff like regional NAT Gateway availability and Route 53 resolver updates on the networking side, plus new opinionated paths like ECS Express Mode and the “EKS capabilities” direction AWS keeps leaning into. There’s also a clear AI and data signal with things like S3 Vectors and the bigger S3 object support. Even if you don’t care about the buzzwords, you should care about what this does to patterns teams will try to roll into your clusters and accounts.

Then we step out of AWS for a minute and talk about Google’s 130,000-node GKE cluster. It’s obviously an extreme case, but those write-ups are still useful because they show what breaks first: control plane pressure, scheduling behavior, networking limits, and how much operational discipline you need when “it scales” stops being a marketing phrase and becomes a daily reality.

And then we hit the spicy one: “kill staging.”

The argument isn’t “YOLO production.” It’s that staging is often a false sense of safety. The more your staging environment diverges from prod, the more it becomes a place where bugs hide, not where bugs get caught. The real conversation is how you test in production responsibly: feature flags, progressive rollouts, canaries, solid observability, and a rollback path that doesn’t rely on heroics.

The thread tying all of this together is pretty simple: the big cloud providers are making it easier to ship faster, but the only way that’s a win is if your platform has guardrails. Otherwise you just move faster into the wall.

Show notes below have all the links if you want to dig into the re:Invent announcements, the GKE story, and the staging debate.