Ship It Weekly - DevOps, SRE, Platform and Cloud Engineering News copertina

Ship It Weekly - DevOps, SRE, Platform and Cloud Engineering News

Ship It Weekly - DevOps, SRE, Platform and Cloud Engineering News

Di: Teller's Tech - DevOps SRE and Cloud Podcast
Ascolta gratuitamente

Offerte di stagione | 0,99 €/mese per i primi 3 mesi

A seguire 9,99 €/mese – si applicano condizioni. Puoi disdire mensilmente.
A proposito di questo titolo

Ship It Weekly is a short, practical recap of what actually matters in DevOps, SRE, cloud infrastructure, and platform engineering.

Each episode, your host Brian Teller walks through the latest outages, releases, tools, and incident writeups, then translates them into “here’s what this means for your systems” instead of just reading headlines. Expect a couple of main stories with context, a quick hit of tools or releases worth bookmarking, and the occasional segment on on-call, burnout, or team culture.

This isn’t a certification prep show or a lab walkthrough. It’s aimed at people who are already working in the space and want to stay sharp without scrolling status pages, cloud updates, and blogs all week. You’ll hear about things like cloud provider incidents, Kubernetes and platform trends, Terraform and infrastructure changes, and real postmortems that are actually worth your time.

Most episodes are 15–30 minutes, so you can catch up on the way to work or between meetings. Every now and then there will be a “special” focused on a big outage or a specific theme, but the default format is simple: what happened, why it matters, and what you might want to do about it in your own environment.

If you’re the person people DM when something is broken in prod, or you’re building the cloud and platform everyone else ships on top of, Ship It Weekly is meant to be in your rotation.

Brian Teller - Teller's Tech - DevOps, SRE and Cloud
Politica e governo
  • Ship It Conversations: Mallory Haigh of PlatformEngineering.org on Why Context Isn't Enough for AI Agents, Harness and Governance, Probabilistic and Hybrid Paths, Agent Identity, and Building Platform Trust Before Agents
    Nov 11 2026

    This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.

    In this Ship It Conversations episode, I talk with Mallory Haigh about why context alone isn't enough for AI agents, the harness and governance layers that actually run them, and why she tells some platform teams to pump the brakes before adding agents at all.

    Mallory is Head of Platform Education and Advocacy at PlatformEngineering.org. She teaches in Platform Engineering University and coaches platform teams through Platform Engineering Consulting, where the job gets jokingly called "platform therapist".

    We start with her New York City analogy. Drop someone in the middle of the city with no directions and they'll get lost, and an agents.md file on its own does the same to an agent. It also needs to know what to do, how to do it, how it'll know it's done, and what it's allowed to touch. Mallory splits that into the harness, which is how the agent does the work, and governance: who and what is allowed, what's safe, and how it's watched.

    Then we get into IDPs as context layers. Mallory says that's partly right, because the IDP and its golden paths are the foundation. What's missing are path specifications. Probabilistic paths are agent-driven, like a read-only PR review. Deterministic paths are your pipelines, like a CI build. Hybrid paths pair an agent with a gate: the agent opens the PR, CI validates it, the agent retries, and a human makes the final call. Cap those retries at three to five, and if an agent always does the same thing with the same outcome, ask whether it should be an agent at all.

    On governance, Mallory says platform engineering is a practice about building trust, and that in the last three weeks alone she's told multiple platform teams to pump the brakes on agents because they can't get human governance right yet. We cover agent identity (specialists, not generalists, built on the RBAC you already have), agents watching terabytes of logs a day for SRE teams, and why every team now has to write down the tribal knowledge it never documented.

    Her advice on where to start: ask why. Then try a read-only PR review agent, move to a hybrid validate-change path, and remember the line from one of her PlatformCon New York workshops: if we can't even write a README for our repos, how are we going to write one for our agents?

    Highlights

    • Why context delivery alone isn't enough for AI agents

    • The harness and governance layers that make up agent infrastructure

    • Observability for agents: token spend, time to completion and retry loops

    • Probabilistic, deterministic and hybrid paths

    • Retry limits, and when an agent should be a checklist instead

    • Pumping the brakes when human governance isn't there yet

    • Agent identity, RBAC and specialist agents

    • Where a platform team should start: ask why, then a read-only PR review agent

    Links

    Mallory on LinkedIn · PlatformEngineering.org · Platform Engineering University · Platform Engineering Consulting · Thinking in Platforms · More episodes · On Call Brief · LMGT Awards

    Mostra di più Mostra meno
    39 min
  • Ship It Conversations: Ryan Packer of BambooHR on Why CTOs Are Coding Again, Building a Software Factory, AI Straining CI/CD, Protecting HR Data, Mid-Career and Junior Engineers, and Why Every Engineer Gets a Team of Agents
    Nov 9 2026

    This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.

    In this Ship It Conversations episode, I talk with Ryan Packer about why a CTO is writing code again, what happens to CI/CD when every engineer runs a fleet of agents, and who trains junior engineers when AI can fix the bugs.

    Ryan is the CTO at BambooHR and a former VP of Engineering at Adobe. He's watched engineering organizations change from Omniture to Adobe to BambooHR, and he says he's spent more time coding this year than in the rest of his career combined.

    We start with why. Ryan will never write production code for his team again, but he wants to use the same tools and learn the same techniques they're learning, and to show an idea in working code instead of a PRD or a Slack message. He's also honest about the limits: his sandbox serves maybe a hundred people, and his team's software serves millions.

    Then we get into the software factory. In Ryan's own version, a customer files a bug, an agent opens the PR, tests it for security and performance, scores it, and ships it if it meets the bar. At BambooHR, pull requests are up almost 80% since the start of the year, and quality has improved by the metrics they track. The part he's most excited about is more at-bats with customers: an idea to a working prototype in a day.

    For platform teams, Ryan says AI has been more of a challenge than a help for CI/CD. BambooHR was already releasing hundreds of times a day, but agents do their best work when they can run and test what they build. Ten, twenty or a hundred agents per engineer means environments that spin up and down fast, with real data. We also cover protecting HR and payroll data: terms with the frontier labs, data retention, and an AI council.

    On careers, Ryan thinks mid-career engineers face the hardest change, and that the ones who keep learning have little to worry about. On junior engineers, he doesn't claim a perfect answer. He no longer needs them to fix bugs, so he suggests making the LLM explain its choices and using an adversarial agent that lists five things it would have done differently. We finish with every engineer managing a team of agents, small pods doing what 10 to 15 people used to, and why he expects the same or more engineers a year from now.

    The big takeaway: if every project in your portfolio has better than a 50% chance of success, you're not being ambitious enough. Put something in there with a 10% chance.

    Highlights

    • Why a CTO is coding again, and why his sandbox isn't production

    • The software factory: a customer bug to an agent PR to a tested release

    • Pull requests up almost 80%, with quality improving

    • More at-bats with customers: idea to working prototype in a day

    • Why AI is straining CI/CD and test environments

    • Protecting HR and payroll data while adopting AI

    • Junior engineers, adversarial agents and making the LLM explain itself

    • Every engineer with a team of agents, and the 10% project

    Links

    Ryan on LinkedIn · BambooHR · BambooHR careers · More episodes · On Call Brief · LMGT Awards

    Mostra di più Mostra meno
    37 min
  • GitHub Blocks pull_request_target by Default, WordPress Update Race Exploited, Polymarket Drained via Hijacked DebugBear Script & Alpine's GitLab Upgrade Missed the Fix
    Nov 6 2026

    This week on Ship It Weekly, GitHub will block pull_request_target in public repos by default from December 2, with brownouts on Mondays, November 9 and 16, 11 AM to 1 PM ET. A WordPress core update race (CVE-2026-119977) is on CISA's exploited list: during a full-package update, a fresh installer can sit for a moment at a public URL under wp-content/upgrade. A hijacked DebugBear script drained about $2.7 million from Polymarket users after DebugBear's DNS was compromised through its registrar. And Alpine Linux explains why upgrading GitLab didn't fix CVE-2026-97229 on its own image: the fix was a patch to Ruby.

    The thread: what actually ran, as opposed to what you think ran. A trigger that runs a fork's code with your secrets, an update that opens its own window, a script served by whoever controls the DNS, and a version number that said "fixed".

    In the lightning round: OpenSSH 10.6p2 fixes a password login bypass on musl builds with PAM off, which is how Alpine builds openssh-server; Debian and Ubuntu patch an APT package swap (CVE-2026-109518); and .NET 8 and 9 reach end of support on Tuesday, November 10.

    The human closer comes back to Alpine's "we cannot rule it out." If an attack hit you this week, could your logs prove it didn't work?

    Highlights

    • pull_request_target: what it runs, and what to check before Monday

    • WordPress: when keeping current is what opens the window

    • DNS, HTTPS and subresource integrity for third-party scripts

    • Registrar lock, MFA and alerts on DNS changes

    • Alpine: GitLab from your own image needs a fixed Ruby too

    • "No evidence" is only as good as the logs you kept

    Links

    pull_request_target blocked by default (GitHub): https://tsn.io/KwebM

    WordPress advisory GHSA-4w3m-c66w-69mg: https://tsn.io/1HGiK

    WordPress upgrade-window RCE (Wordfence): https://tsn.io/Pc6X2

    Polymarket postmortem: https://tsn.io/rOc2M

    DebugBear on the registrar DNS compromise: https://tsn.io/4BjIg

    Polymarket losses and refunds (Hackread): https://tsn.io/qNhoe

    Alpine's GitLab security incident: https://tsn.io/GpNoR

    OpenSSH 10.6p2 release notes: https://tsn.io/dQHbG

    Alpine openssh-server advisory: https://tsn.io/lExh2

    APT CVE-2026-109518 (Debian DSA-6607-1): https://tsn.io/LSjTb

    .NET 8 and 9 end of support: https://tsn.io/7NC5R

    This week's On Call Brief: https://tsn.io/XJLrm

    More episodes and show notes: https://tsn.io/NqkdP

    On Call Brief: https://tsn.io/Gpz2d

    LMGT Awards: https://tsn.io/lAERA

    Mostra di più Mostra meno
    16 min
adbl_web_anon_alc_button_suppression_t1
Ancora nessuna recensione