DevOps Paradox

DOP 347: Cozystack Turns Bare Metal Into a Managed Services Platform

#347: Andrei Kvapil has been around Kubernetes since the early days. Contributor to Cilium, Kubevirt, and a handful of other projects you probably use without realizing it. He is also the maintainer of Cozystack, a CNCF sandbox project, and the CEO of Aenix, the company behind it. The thesis: Kubernetes should be boring. Not exciting, not cutting-edge, not the thing everyone argues about. Boring like the Linux kernel is boring. Something that sits underneath everything and nobody needs to think about. Viktor takes it one step further and says it should be invisible -- developers should never need to know Kubernetes exists, any more than they need to know what kernel their laptop is running. Cozystack is Andrei's answer to a specific problem. ISPs, banks, finops shops, anyone in Europe who cannot or will not put their data in AWS -- they all want to offer managed databases, managed Kubernetes, object storage, the whole stack. Building that from scratch is hard. Running OpenStack requires a dedicated team that does nothing but tune networking. Cozystack bundles the pieces (Kubevirt, CloudNative Postgres, Cilium, etc) into one product with an aggregation API layer on top of Kubernetes itself. Helm becomes the extension language. The platform becomes a product. Then the conversation takes a turn. Andrei is the CEO of a bootstrapped company and he says flatly that without AI the company would not exist. Claude Code is moving Kanban cards. Clients send files generated by their AI agent and Aenix feeds those files to their AI agent to generate the response. Andrei's only wish is for this middle step -- him -- to stop existing. Let the agents talk to each other and call him when something actually matters. There is a hiring question in here too. If the next generation of engineers starts their career with AI on the first commit, do they ever build the mental model that lets them guide the agent when it goes wrong? Andrei thinks you still need deep understanding for anything serious. Viktor agrees. Speed versus quality is still a choice, and juniors who skip the "write it three times until it stops being garbage" phase are going to feel that gap eventually. Andrei's contact information: LinkedIn: https://www.linkedin.com/in/kvaps/ [https://www.linkedin.com/in/kvaps/] YouTube channel: https://youtube.com/devopsparadox [https://youtube.com/devopsparadox] Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ [https://www.devopsparadox.com/review-podcast/] Slack: https://www.devopsparadox.com/slack/ [https://www.devopsparadox.com/slack/] Connect with us at: https://www.devopsparadox.com/contact/ [https://www.devopsparadox.com/contact/]

DOP 346: Fighting AI in Your Project Is a Terrible Mistake

#346: Drive-by PRs, AI slop, maintainers burning out -- the open source world is having a meltdown and everyone wants to blame the robots. Viktor isn't buying it. The real problem started long before AI. Contributing to most open source projects has always depended on tribal knowledge and obscure docs nobody reads. AI didn't break that. It exposed it. When contributions were trickling in, you could get away with onboarding people via vibes. Now that contributions are a firehose, you can't. Viktor's take cuts in a direction that will annoy a lot of maintainers: your primary job is empowering contributors, not gatekeeping. And if a 20,000-line PR is drowning you, the answer isn't to block everybody. The answer is to change the whole review cycle -- because yesterday you were complaining about not enough contributions and today you're complaining about too many. That's a great problem to have. Solve it. Here's the part that will upset people. Viktor reframes what a developer's job actually is. If you think your role is typing on a keyboard, you're going to be disappointed. Your role is becoming a product manager. Asking the agent did you look at this, are you sure, what about that. Your job is no more. You just didn't receive the memo. There's also a thread running through the episode about auditing. Can you actually assess the health of an open source dependency you depend on? Viktor dares Darin to audit Kubernetes. Or curl. Or anything. Humans can't do it at all. AI can -- imperfectly, but better than nothing. Which means the old enterprise model (pay Red Hat, they'll handle it) starts to wobble when the value of someone else handling it drops because the tools can handle it for you. And there's a prediction. Right now when you ask AI to build something, it picks libraries based on training data. But what happens when the agent actually goes shopping -- analyzing projects, reading docs, deciding which dependencies to pull in? That changes the open source landscape in a way nobody is ready for. The episode ends somewhere quieter. Contributors, human or AI, should be cherished and trained over time. The hostility toward AI contributions is coming from maintainers who forgot that investing in new contributors is the job. The tools will make a mess. Then they will make less of a mess. Eventually we will be arguing about whether the feature should exist at all -- not whether the code compiles. YouTube channel: https://youtube.com/devopsparadox [https://youtube.com/devopsparadox] Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ [https://www.devopsparadox.com/review-podcast/] Slack: https://www.devopsparadox.com/slack/ [https://www.devopsparadox.com/slack/] Connect with us at: https://www.devopsparadox.com/contact/ [https://www.devopsparadox.com/contact/]

DOP 345: From Chat Prompt to Working Software with Kiro

#345: Vibe coding works fine until your project gets complicated. That's the gap Amit Patel and his team at AWS built Kiro to fill. The tool launched with about six people in mid-2024, hit GA around October 2025, and the team still fits in a single room -- maybe a seven-pizza team by Darin's math. The core idea is spec-driven development, but not the kind where business analysts disappear for five years and come back with a document nobody needs anymore. Amit's version: you tell the agent what you want in a chat prompt, it writes the spec for you, and you iterate on it. Twenty minutes of back and forth and you've got requirements, a design, and a task breakdown. Then the agent executes. Two to three days later, working software. Here's where it gets interesting. Amit frames the human role as bookends. At the front, you define intent -- what needs to exist and why. At the back, you verify that what got built actually matches. Everything in the middle? That's where the tooling lives. And that middle is getting wider every month as agents run longer, handle more turns, and start working in parallel. But the gap between 'I can build it' and 'I built it right' is real. Amit's S3 example nails it. Ask an LLM to build a file upload app and you'll get one that works. Encryption at rest, encryption in transit, KMS, bucket policies -- none of that shows up unless you know to ask for it. The LLM will generate all of it on request. It just won't volunteer it. That's the experience gap, and it's why junior developers still need to become senior developers the old-fashioned way. One story that landed: a product manager on Amit's team used Kiro to go from conversation to working prototype overnight. Not a wireframe. Not a doc. A demo the engineering team could put into production. The roles aren't disappearing -- they're getting more fluid. The value was never in the writing. It was always in knowing what needed to be built. Kiro is now widely adopted inside AWS, with both an IDE and a CLI. Where it's headed next: agents that run in the background, handle multiple tasks at once, and get verified with formal methods instead of just hoping the output is right. But Amit's honest about the limits -- steering file adherence is, in his words, an art in itself. Non-deterministic LLMs will ignore your rules sometimes. Just like humans. Amit's contact information: LinkedIn: https://www.linkedin.com/in/amit-patel-040453/ [https://www.linkedin.com/in/amit-patel-040453/] YouTube channel: https://youtube.com/devopsparadox [https://youtube.com/devopsparadox] Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ [https://www.devopsparadox.com/review-podcast/] Slack: https://www.devopsparadox.com/slack/ [https://www.devopsparadox.com/slack/] Connect with us at: https://www.devopsparadox.com/contact/ [https://www.devopsparadox.com/contact/]

DOP 344: KubeCon EU 2026 Review

#344: Kubernetes is boring now. That's the whole point. KubeCon EU 2026 in Amsterdam -- likely the biggest KubeCon ever at more than 13,000 attendees -- made one thing extremely clear: the container orchestrator is done being interesting on its own. Every keynote, every new sandbox project, every vendor announcement pointed the same direction. AI. Inference. Agents. NVIDIA donated a DRA driver for GPUs to CNCF. Google open-sourced their cluster autoscaler and shipped a DRA driver for TPUs. Red Hat brought LLM-D for disaggregated inference. NVIDIA contributed the KAI Scheduler for AI workloads. The Gateway API now has an inference extension in beta -- model routing baked directly into the Kubernetes networking layer. And here's the thing Whitney pointed out that should make everyone pause: you can't even run inference workloads in containers. They can escape. You need micro VMs. So the container orchestrator is orchestrating things that aren't containers. The platform engineering conversation shifted too. The bottleneck isn't technology anymore -- it's culture. Getting teams to work together differently. And if your company can't trust its own employees to make decisions, good luck trusting agents. Viktor's take on the determinism objection was blunt: agents aren't deterministic, but neither are you. You just think you are. One thread that kept surfacing: agents as first-class platform users. Not agents doing agent things -- agents as the users your platform serves. Viktor sees it in real time -- pull requests created by agents, reviewed by his Claude, responses written by the submitter's agent. Humans aren't even in the conversation anymore. The new CNCF sandbox projects tell the story too. LLM-D, KAI Scheduler, Higress (AI-native gateway). And then Velero -- the Kubernetes backup tool that everyone assumed was already CNCF -- finally donated by Broadcom. Which raises a fair question: is CNCF becoming a dumping ground for projects companies don't want to maintain? Probably some of both. Viktor compared the current state to the first five years of Kubernetes -- everyone focused on low-level components, trying to figure out how to combine 57 different tools. The next wave will be higher-level platforms that bundle all of it. And somewhere underneath it all, the mainframe keeps running. Viktor's bet: it'll outlive AI. YouTube channel: https://youtube.com/devopsparadox [https://youtube.com/devopsparadox] Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ [https://www.devopsparadox.com/review-podcast/] Slack: https://www.devopsparadox.com/slack/ [https://www.devopsparadox.com/slack/] Connect with us at: https://www.devopsparadox.com/contact [https://www.devopsparadox.com/contact/]

DOP 343: Your APIs Were Never Built to Be the Front Door

#343: Here's the thing about your company's APIs -- they were built for your own engineers to use inside your own software. Nobody designed them to be the front door. But that's exactly what's happening. Matt DeBergalis, CEO of Apollo GraphQL, makes a pretty compelling case that AI agents are turning internal APIs into the actual interface between companies and customers. Not the website. The APIs themselves. And most of them aren't ready for that. At all. Think about what happens when you point a model at a typical REST API. GitHub's API returns hundreds of fields for a single repository object. Fine when another service is calling it. But a model? All those extra fields are context you're paying for, and they make the model hallucinate. Matt says you need something between the model and all those backend services -- an orchestration layer that takes one request and handles the mess underneath. That's where GraphQL comes in. He draws a parallel that'll land immediately if you've been in this space a while. APIs right now are pets -- handwritten, named, carefully managed. But AI-generated code is about to produce way more microservices, which means way more APIs. They're going to become cattle. And just like containers needed Kubernetes, APIs are going to need declarative infrastructure to manage them at scale. The conversation takes an interesting turn when Darin pushes back on the idea that developers are becoming architects. His take: we're becoming product managers. Matt says both. Viktor throws in code reviewers. Matt's own story backs it up -- he codes more as CEO than he did as CTO, because AI handles the parts he never had time to learn. He doesn't know modern React. Doesn't need to. One more thing that should make any tech company uncomfortable: if AI agents are how customers find you now, what happens to your docs-page-driven acquisition funnel? Apollo's already made the shift -- their first audience for documentation is the models, not the humans. Matt's contact information: LinkedIn: https://www.linkedin.com/in/debergalis/ [https://www.linkedin.com/in/debergalis/] YouTube channel: https://youtube.com/devopsparadox [https://youtube.com/devopsparadox] Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ [https://www.devopsparadox.com/review-podcast/] Slack: https://www.devopsparadox.com/slack/ [https://www.devopsparadox.com/slack/] Connect with us at: https://www.devopsparadox.com/contact/ [https://www.devopsparadox.com/contact/]