Try reloading the player or open this episode directly on YouTube.
In this episode of Ship It Weekly, Brian discusses the implications of new AI interfaces on existing responsibilities. He covers McKinsey's AI tool vulnerability, Kafka's diskless topics model, Google's acquisition of Wiz, AWS Copilot's end, and Kubernetes' AI Gateway initiative.
Now Playing
McKinsey AI Flaw, Kafka Goes Diskless, Google Buys Wiz, AWS Copilot Ends, and AI Gateway on Kubernetes
Ship It Weekly
0:0014:56
Chapters
Jump to a section in this episode.
Speed & share
Transcript
Everybody wants the new interface. Very few people
want the new responsibility. Because the second
a company adds AI to an internal workflow, changes
the paved road in cloud, or pushes a new gateway
layer into production, somebody has to own the
policy, the logs, the rollback, and the fallout.
That somebody is usually us. Hey, I'm Brian Teller.
I work in DevOps and SRE, and I run Teller's
Tech. This is Ship It Weekly, where I filter
the noise and focus on what actually changes
how we run infrastructure and own reliability.
Show notes and links are on shipitweekly .fm.
If the show's been useful, follow it wherever
you listen. Ratings help way more than they should.
And if you want more signal between episodes,
check out OnCallBrief .com. We've got five main
stories today, then the lightning round, and
we'll wrap with the human closer. We're starting
with McKinsey because an internal AI tool vulnerability
is a nice reminder that internal does not mean
low risk. Then Kafka because the diskless topics
work is one of the more interesting architecture
signals I've seen in a while. After that, Google
officially closes the Wiz deal, which tells you
a lot about where the cloud fight is headed.
Then AWS is sunsetting co -pilot CLI, which is
one of those stories that sounds small right
up until it lands on your team's migration list.
And finally, Kubernetes is standing up an AI
gateway working group, which is probably the
clearest sign yet that AI traffic is becoming
regular platform traffic, just with stranger
payloads. Let's start with McKinsey, because
I think this is one of those stories where the
real lesson is less flashy than the headline.
McKinsey said on March 11th that it was alerted
by a security researcher to a vulnerability related
to its internal AI tool. Lilly confirmed it.
fixed it within hours and found no evidence client
data or client confidential information had been
accessed by the researcher or any other unauthorized
third party. And sure, the official takeaway
there is we moved quickly and no client data
appears to have been accessed. Fine. That part
matters. But the reason I think this is worth
covering is that it keeps happening across the
industry, where companies treat internal AI tools
like they are somehow lighter weight than normal
applications. They are not. The second an internal
AI tool can touch company knowledge, shape decision
flow, or influence what people trust, it stops
being a novelty and starts being part of your
operating surface. Same auth questions. Same
blast radius questions. Same logging questions.
Same need for somebody to own the thing when
it goes weird. That inference is based on the
kind of access and sensitivity McKinsey itself
describes around Lilly and on the fact that the
company treated the issue as a serious security
matter requiring forensic review. So the practical
lesson here is simple. Internal AI app is not
a special category. It is still an app. If your
org has quietly stood up a chatbot, assistant,
code helper, search helper, support helper, whatever,
and it can see real context or influence real
work, then congratulations. You now have another
production service wearing a friendlier mask.
One thing to check this week. Make a list of
every internal AI thing your company now treats
as normal. Then ask the boring questions. What
can it read? What can it write? What identities
does it assume? What gets logged? What would
forensics look like after a bad day? If nobody
can answer that clearly, there's your work. Now
to the most infrastructure -shaped story in the
episode. Kafka's KIP -1150 proposes diskless
topics, where topic data is stored durably in
object storage instead of broker disks. Replication
is delegated to object storage, and no broker
is uniquely the leader of a partition. The proposal
also explicitly says early diskless topics would
not immediately support compaction or transactional
writes, and it describes append latency as buffering
plus remote upload time. with p99 upload times
in the rough 200 to 400 millisecond range in
the design notes that is not a minor improvement
That is a pretty serious statement about where
cloud economics keep pushing distributed systems.
Because a lot of the old assumptions around platforms
like Kafka came from a world where durable local
storage and broker -centric replication made
obvious sense. In cloud, especially once across
AZ traffic and storage costs show up in the bill
at scale, those assumptions get expensive. This
proposal is basically saying maybe the right
answer is not to keep optimizing the old center
of gravity forever. Maybe the center of gravity
moved. And that's what makes this story interesting
to me. Not that every team is about to run diskless
Kafka tomorrow. Most won't. The interesting part
is the architecture honesty. It is admitting
that cloud native economics can eventually force
cloud native redesign. not just better tuning
knobs. So if you run distributed systems, this
is the kind of story worth paying attention to.
Not because you need the feature today, but because
it is a sign that the old durable core assumptions
are starting to crack in places where cost and
scale finally get loud enough. One thing worth
asking this week, where are you still paying
an old architecture tax? Because the system was
designed around hardware or topology assumptions
that no longer match the environment you actually
buy. Next up, Google and Wiz. Google announced
on March 11th that it completed its acquisition
of Wiz, that Wiz will join Google Cloud, and
that Wiz will keep its brand and continue securing
customers across all cloud environments. TechCrunch
reported the deal at $32 billion and called it
Google's biggest acquisition ever. That matters
because this is not just a big company buying
a hot security startup. It is Google spending
an absurd amount of money on the idea that cloud
security posture, multi -cloud visibility, and
AI -era security operations are now part of the
core platform fight. And honestly, that tracks
with how teams actually operate now. The cloud
conversation is not just compute anymore. It
is identity posture, exposure management, policy.
visibility across ugly, mixed environments, and
whether your security layer still works once
half the company is touching three clouds and
six SaaS platforms and some new AI service somebody
turned on last week. Google's own announcement
frames the acquisition as a bet on cloud security
and helping organizations build across any cloud
or AI platform. That is the real takeaway for
me. Security is not bolted onto platform anymore.
It is part of the platform buying decision itself.
So if your company still talks about cloud strategy
over here and security strategy over there, like
they are two separate decks, that feels increasingly
fake. Those are the same conversations now, or
at least they should be. Now for the AWS story
that is probably already annoying somebody. AWS
announced that co -pilot CLI will reach end of
support on June 12th, 2026. AWS says the tool
will still exist as an open source project on
GitHub. but it will no longer receive new features
or security updates from AWS. And the migration
guidance points people towards ECS Express Mode
or AWS CDK Layer 3 constructs. This is exactly
the kind of platform story that sounds smaller
than it is. Because Copilot was not just CLI.
For a lot of teams, it was the we can ship containers
on AWS without building an entire internal platform
first path. It was the paved road. And when the
vendor changes the paved road, teams inherit
migration work whether they asked for it or not.
That's the part cloud people know in their bones.
The easy path is temporary. the recommended abstraction
is rented. And even when the replacement makes
sense, you still pay retraining tax, docs tax,
migration tax, and that wonderful tax where somebody
asks you why you spent time changing this when
it was technically still working yesterday. I
think the bigger signal here is that AWS is still
refining how opinionated it wants to be around
container delivery. Fair enough. But if you build
on vendor convenience, you need an exit story
before the deprecation notice shows up. not after.
So one practical check here. If your team depends
on a managed or vendor -blessed workflow for
something important, do you already know the
off -ramp? Last main story, and this one is a
really clean signal. Kubernetes announced the
AI Gateway Working Group on March 9th. The group
says it is focused on standards and best practices
for networking infrastructure that supports AI
workloads in Kubernetes, including token -based
rate limiting, fine -grained access controls
for inference APIs, payload inspection for routing
and guardrails, and active proposals around payload
processing to defend against malicious prompts
and prompt injection. It is also looking at egress
patterns for securely routing traffic to external
AI services. is a loud clue about where the real
work is headed. Because once the Kubernetes ecosystem
starts formalizing the gateway and policy layer
around AI traffic, the interesting part is no
longer just which model are we calling or what
prompt trick did somebody discover this week.
The interesting part becomes operational. Who
can hit what? How traffic gets shaped? What gets
inspected? What gets cached? What gets blocked?
What happens when external model providers are
in the path? what gets logged when a request
goes sideways. This is platform work, which is
why I like this story so much. It cuts past a
lot of hype and lands in a place that feels real.
If your org is already exposing inference endpoints
or routing to outside model providers, treat
that traffic like any other sensitive path. Rate
limit it, wrap auth around it, think about payload
handling, think about egress control, and think
about observability. It's the same game, just
weirder packets. A few quick ones before we wrap.
Amazon Bedrock added two new CloudWatch metrics,
time to first token and estimated TPM quota usage.
That matters because it gives teams first token
latency and quota consumption visibility without
client -side instrumentation. And both metrics
are updated every minute for successfully completed
requests. Cloudflare now returns structured JSON
for its one XXX errors when clients send accept
application slash JSON or application slash problem
plus JSON. And those responses follow RFC 9457.
Tiny story, but a good one for automation, agents,
and anything that should not have to scrape messy
error blobs to figure out what happened. AWS
S3 server access logs now include source region
information automatically at the end of each
log entry, which makes it easier to spot cross
-region access patterns that can quietly turn
into cost or latency problems. AWS Config added
30 more supported resource types in early March,
including Bedrock Agent core resources like aws
bedrock agent core gateway and aws bedrock agent
core memory which is just another reminder that
compliance and inventory scope keep expanding
while nobody is looking and a reminder that bedrock
agent core runtime now supports stateful mcp
server features like elicitation sampling and
progress notifications with each user session
running in a dedicated micro vm and keeping context
across interactions that is the kind of thing
that makes agent systems feel a lot less like
demos and a lot more like infrastructure. I think
the cleanest takeaway this week is that the new
interface does not remove the old responsibilities.
McKinsey's Lily story says your internal AI app
is still an app. Kafka's diskless push says cloud
economics eventually force architectural honesty.
Google Closing Wiz says security and platform
strategy are now tangled together at the executive
level. Copilot Getting Sunset says convenience
is borrowed. And the Kubernetes AI Gateway effort
says the next layer of work is going to be policy,
routing, inspection, and traffic control around
these systems, not just model selection. So the
job is still the job. Make the control plane
observable. Make permissions explicit. Keep the
rollback clean. Don't let internal turn into
unreviewed. And don't mistake a new interface
for a new set of operational laws. Most of the
laws are the same. They just keep showing up
in new clothes. Alright, that's it for this week
of Ship It Weekly. Quick recap. McKinsley's Lilly
vulnerability and why internal AI tools are still
real attack surfaces. Kafka's diskless topics
push and what it says about cloud shaping architecture.
Google officially closing the Wiz acquisition.
AWS sunsetting co -pilot CLI. And Kubernetes
standing up an AI gateway working group because
AI traffic is becoming platform traffic whether
we like it or not. Links and show notes are on
shipitweekly .fm. You can also find the video
versions on YouTube. And if you want the DevOps
news before the show, you can check out oncallbrief
.com. If this episode was useful, follow or subscribe
wherever you listen. And send it to the person
on your team who keeps hearing Just Add AI while
quietly inheriting all the policy, observability,
and guardrail work that comes with it. I'm Brian,
and I'll see you next week.
McKinsey AI Flaw, Kafka Goes Diskless, Google Buys…
For this episode, the thing that kept showing up was not really “AI” by itself.
It was responsibility.
More specifically, what happens when companies roll out a new interface, a new abstraction, or a new “easy path,” and then quietly hand platform teams all the responsibility that comes with it.
That’s what tied these stories together for me.
McKinsey had to publicly deal with a vulnerability in Lilli, which is useful not because it turned into some huge apocalyptic breach story, but because it reminds people that internal AI tools are still real systems. They may look friendly. They may be framed like helpers. But once they can touch company knowledge, influence decisions, or sit in the middle of a workflow people trust, they stop being side tools. They become part of the operating surface.
And that means all the old questions come right back.
Who can access it. What can it read. What can it write. What does it trust. What gets logged. What happens when somebody uses it in a way nobody really modeled.
That is the part people keep wanting to skip.
Everybody wants the new interface. Very few people want the old responsibilities that come with it.
The Kafka story hit a different version of the same theme.
Diskless topics are interesting because they feel like architecture honesty. Not hype. Not branding. Just a pretty direct acknowledgment that cloud economics eventually force you to revisit assumptions that used to feel settled. If durable local storage and broker-led replication were the obvious center of gravity before, maybe they are not the obvious center of gravity now. That is a much more useful kind of story to me than most “future of AI” noise, because it is really about something deeper: when the environment changes enough, old architecture starts charging rent.
And a lot of teams are probably living that right now, even outside Kafka.
You see it when the old design still technically works, but it works in a way that is more expensive, more awkward, or more fragile than anybody wants to admit. At some point, tuning stops being the answer. The answer becomes rethinking what the system is centered around in the first place.
Then there’s Google closing the Wiz acquisition, which to me reads less like a flashy M&A story and more like an admission about where the cloud fight actually is now.
The fight is not just compute. It is not just managed services. It is not just who has the nicest product page or the most polished launch event. It is posture. Visibility. Exposure. Identity. Policy. Security as part of the actual platform choice.
That feels obvious if you live in this space, but it is still worth saying out loud because companies still act like cloud strategy and security strategy are two separate conversations. I buy that less and less. Not when environments are this messy. Not when AI is adding new surfaces. Not when half the real work is figuring out what is running where, who can touch it, and what your blast radius looks like when somebody gets it wrong.
The AWS Copilot story is kind of the same lesson again, just in a more familiar cloud-ops form.
The paved road moved.
That’s really the story.
And platform teams know exactly what that means. It means the thing that felt like the safe, vendor-approved path now has an off-ramp. It means migration work. Retraining. Documentation churn. Re-explaining choices to teams that thought the answer was already settled. It means carrying the cost of somebody else’s product direction.
That is why I keep coming back to the idea that convenience in cloud is borrowed.
Sometimes borrowing it is absolutely worth it. I am not against paved roads. Most teams should probably use more of them, not less. But the tradeoff is always there. When the road changes, you move too. And if you have not thought about the exit story in advance, the migration always feels more annoying than it should.
Then the Kubernetes AI Gateway Working Group rounds the whole episode out in a way I really like, because it cuts through a lot of the dumbest AI discourse.
The interesting question is not “do you believe in AI” or “what model is best this week.”
The interesting question is what happens when AI traffic becomes normal platform traffic.
Because once that happens, the conversation gets a lot more real. Now it is rate limiting. Access control. Payload inspection. Egress policy. Caching. Guardrails. Prompt injection defenses. Logging. Routing. Normal boring platform words. Which is exactly why I like the story. It is a sign that the industry is moving from novelty into operations.
And that is usually where the truth shows up.
If I had to boil the whole episode down, I think it comes back to this:
The new interface does not remove the old responsibilities.
That is true for internal AI tools. It is true for cloud architecture. It is true for security acquisitions. It is true for vendor paved roads. And it is definitely true for AI-shaped traffic once it starts touching real systems.
There’s always a shiny version of the story companies want to tell.
Smarter tools. Faster delivery. Simpler workflows. Better leverage. A more intelligent future.
And sure, some of that is real.
But the operator version of the story always lands a little differently.
What are the trust boundaries. What gets logged. What is actually enforced. How clean is rollback. What happens when the vendor changes direction. What assumptions are now too expensive to keep pretending are normal. Who owns the control plane after all this stuff hardens into real production dependency.
That’s where this episode lived for me.
Not in the hype. Not in the demo. Not in whether the new thing sounds cool.
More in the handoff point where new capability turns into somebody else’s operational burden.
And most of the time, that somebody is us.
📝 Notes
Show Notes
This week on Ship It Weekly, Brian looks at what happens when new interfaces create old responsibilities.
McKinsey patched a vulnerability in its internal AI tool Lilli, Kafka contributors are pushing a diskless-topics model that rethinks durability and replication in cloud environments, and Google officially closed Wiz acquisition in one of the biggest cloud-security moves. Plus: AWS is sunsetting Copilot CLI, Kubernetes launches an AI Gateway Working Group.
For this episode, the thing that kept showing up was not really “AI” by itself.
It was responsibility.
More specifically, what happens when companies roll out a new interface, a new abstraction, or a new “easy path,” and then quietly hand platform teams all the responsibility that comes with it.
That’s what tied these stories together for me.
McKinsey had to publicly deal with a vulnerability in Lilli, which is useful not because it turned into some huge apocalyptic breach story, but because it reminds people that internal AI tools are still real systems. They may look friendly. They may be framed like helpers. But once they can touch company knowledge, influence decisions, or sit in the middle of a workflow people trust, they stop being side tools. They become part of the operating surface.
And that means all the old questions come right back.
Who can access it.
What can it read.
What can it write.
What does it trust.
What gets logged.
What happens when somebody uses it in a way nobody really modeled.
That is the part people keep wanting to skip.
Everybody wants the new interface. Very few people want the old responsibilities that come with it.
The Kafka story hit a different version of the same theme.
Diskless topics are interesting because they feel like architecture honesty. Not hype. Not branding. Just a pretty direct acknowledgment that cloud economics eventually force you to revisit assumptions that used to feel settled. If durable local storage and broker-led replication were the obvious center of gravity before, maybe they are not the obvious center of gravity now. That is a much more useful kind of story to me than most “future of AI” noise, because it is really about something deeper: when the environment changes enough, old architecture starts charging rent.
And a lot of teams are probably living that right now, even outside Kafka.
You see it when the old design still technically works, but it works in a way that is more expensive, more awkward, or more fragile than anybody wants to admit. At some point, tuning stops being the answer. The answer becomes rethinking what the system is centered around in the first place.
Then there’s Google closing the Wiz acquisition, which to me reads less like a flashy M&A story and more like an admission about where the cloud fight actually is now.
The fight is not just compute. It is not just managed services. It is not just who has the nicest product page or the most polished launch event. It is posture. Visibility. Exposure. Identity. Policy. Security as part of the actual platform choice.
That feels obvious if you live in this space, but it is still worth saying out loud because companies still act like cloud strategy and security strategy are two separate conversations. I buy that less and less. Not when environments are this messy. Not when AI is adding new surfaces. Not when half the real work is figuring out what is running where, who can touch it, and what your blast radius looks like when somebody gets it wrong.
The AWS Copilot story is kind of the same lesson again, just in a more familiar cloud-ops form.
The paved road moved.
That’s really the story.
And platform teams know exactly what that means. It means the thing that felt like the safe, vendor-approved path now has an off-ramp. It means migration work. Retraining. Documentation churn. Re-explaining choices to teams that thought the answer was already settled. It means carrying the cost of somebody else’s product direction.
That is why I keep coming back to the idea that convenience in cloud is borrowed.
Sometimes borrowing it is absolutely worth it. I am not against paved roads. Most teams should probably use more of them, not less. But the tradeoff is always there. When the road changes, you move too. And if you have not thought about the exit story in advance, the migration always feels more annoying than it should.
Then the Kubernetes AI Gateway Working Group rounds the whole episode out in a way I really like, because it cuts through a lot of the dumbest AI discourse.
The interesting question is not “do you believe in AI” or “what model is best this week.”
The interesting question is what happens when AI traffic becomes normal platform traffic.
Because once that happens, the conversation gets a lot more real. Now it is rate limiting. Access control. Payload inspection. Egress policy. Caching. Guardrails. Prompt injection defenses. Logging. Routing. Normal boring platform words. Which is exactly why I like the story. It is a sign that the industry is moving from novelty into operations.
And that is usually where the truth shows up.
If I had to boil the whole episode down, I think it comes back to this:
The new interface does not remove the old responsibilities.
That is true for internal AI tools.
It is true for cloud architecture.
It is true for security acquisitions.
It is true for vendor paved roads.
And it is definitely true for AI-shaped traffic once it starts touching real systems.
There’s always a shiny version of the story companies want to tell.
Smarter tools.
Faster delivery.
Simpler workflows.
Better leverage.
A more intelligent future.
And sure, some of that is real.
But the operator version of the story always lands a little differently.
What are the trust boundaries.
What gets logged.
What is actually enforced.
How clean is rollback.
What happens when the vendor changes direction.
What assumptions are now too expensive to keep pretending are normal.
Who owns the control plane after all this stuff hardens into real production dependency.
That’s where this episode lived for me.
Not in the hype.
Not in the demo.
Not in whether the new thing sounds cool.
More in the handoff point where new capability turns into somebody else’s operational burden.
And most of the time, that somebody is us.