loader from loading.io

DOP 362: Feature Flags vs Canary Deployments

DevOps Paradox

Release Date: 08/05/2026

DOP 363: Is Your Website Agent-Ready? show art DOP 363: Is Your Website Agent-Ready?

DevOps Paradox

#363: Three waves of the web, and you are late for the third one. The 90s were about getting a browser to render your page at all. The early 2000s were about SEO, or as Darin puts it, sell me all the ads ready. Now it is agent ready, and Cloudflare built a scoreboard for it at [isitagentready.com](https://isitagentready.com/). The devopsparadox.com site scored about 70 out of 100 and then went down when Cloudflare added new checks. Run yours. You will be sad. Viktor thinks the framing is slightly off, though, and the correction is the good part. Optimizing for agents that browse your site is...

info_outline
DOP 362: Feature Flags vs Canary Deployments show art DOP 362: Feature Flags vs Canary Deployments

DevOps Paradox

#362: Feature flags or canary deployments - do you need both? Viktor puts it to Alex Casalboni from Unleash, who says he argues about this with his colleagues roughly every day, and the answer lands clean. Switching a hostname, a database, an API vendor? That is infrastructure, nothing to do with who the user is, so keep your canaries and your blue-green. But a canary switches one thing at a time. Try running three A/B tests and ten behavioral changes through it and the whole approach buckles. Anything that needs to know who the user is belongs in a flag. Different layers of the stack,...

info_outline
DOP 361: When Code Got Cheap, Reviewing Got Expensive show art DOP 361: When Code Got Cheap, Reviewing Got Expensive

DevOps Paradox

#361: Picture a 6,000-line pull request landing in your project from someone you've never heard of. Every test passes - yours, theirs, all of it. And you can tell it was generated. Not assisted. Generated. What do you do with it? Viktor's first move is to poke the premise: how do you even know it was generated and not assisted? You can't. Nobody can. That distinction is already gone. So the real question isn't whether AI wrote it. It's what a maintainer is for. Viktor's answer is blunt - a maintainer's first job is to guide people in and help them contribute, and if you think your job is...

info_outline
DOP 360: What Is an AI SRE? show art DOP 360: What Is an AI SRE?

DevOps Paradox

#360: Assume your production systems go sideways at 3:00am. Your phone doesn't ring. You wake up to a clean incident report - the system caught the problem, fixed itself, and left a Slack note saying it handled things at 3:15. Would you trust it? Viktor wouldn't, not at first. Same as a new hire, a new tool, a new anything. Trust gets earned. A few months in, if it hasn't messed up, then maybe. So what's actually new? We had self-healing in decades past, and Kubernetes brings a crashed pod back without anyone awake to watch. Birol Yildiz, co-founder and CEO of ilert, puts the line where it...

info_outline
DOP 359: Demos in the Age of AI Agents show art DOP 359: Demos in the Age of AI Agents

DevOps Paradox

#359: When was the last time you sat through a 30-minute product demo and walked away actually knowing anything? You would learn more from five minutes hands-on than an hour of watching someone else drive. Now you have help. An agent can watch the 30-minute video, play in the sandbox, read every page of the docs, and come back before you finish your coffee with a verdict - tried it, does not work, next. The agent is the new tire kicker. So if you are a vendor, an open source maintainer, or the person building the internal app nobody outside the building ever sees, the demo you have been giving...

info_outline
DOP 358: Just-in-Time Access for AI Agents show art DOP 358: Just-in-Time Access for AI Agents

DevOps Paradox

#358: Production is on fire. You need access to one table you have never touched. So you file an access request, then phone the desk to say you filed it, then Slack them to say you phoned, then walk over to say you Slacked. Twenty-five minutes later the incident has resolved itself and the customer has already left. That is the setup, and Ofir Stein has lived the other side of it. He is the CTO and co-founder of Apono, and before that he was an engineering leader who felt the same pain every day - not because he hated security, but because he hated being blocked. There is a difference, and the...

info_outline
DOP 357: What Is Spec-Driven Development? show art DOP 357: What Is Spec-Driven Development?

DevOps Paradox

#357: Type a prompt, get code, fix the hallucinations, type another prompt. That is vibe coding, and it is a fine place to start. It is a terrible place to stay. So what comes next - and is spec-driven development actually it, or just waterfall wearing a new hat? Here is the reframe that runs the whole conversation: everybody already works from a spec. Even the person who swears they are winging it has a spec in their head - which language, where it runs, what it does. The real question was never specs or no specs. It is whether you write them like waterfall, one giant document before anyone...

info_outline
DOP 356: Warehouse Robots Are a Distributed System show art DOP 356: Warehouse Robots Are a Distributed System

DevOps Paradox

#356: Fleet management means one thing to a DevOps engineer and something completely different to Tomas Kovacovsky. To Viktor it is a CD problem - a fleet of Kubernetes clusters he would rather not babysit. To Tomas it is hundreds of physical robots rolling around a warehouse, picking orders, dodging each other, and working very hard not to lose their connectivity. Tomas is the CTO of Brightpick, where the robots are not the kind you yell at for bumping into a chair. They are three-meter-tall autonomous pickers - some telescoping up to six - that find their way using lidar, recognize items...

info_outline
DOP 355: Why AI Coding Slows Down Code Review show art DOP 355: Why AI Coding Slows Down Code Review

DevOps Paradox

#355: Picture your engineering team a year from now. A coding agent doing the coding. A testing agent on tests. A security agent on security. An infrastructure agent on infrastructure. All of them wired into GitHub and Jira, all of them working right alongside the humans. Not science fiction either - Atlassian and GitHub are already shipping these features. So out come the stats everyone loves to quote. AI code introduces 1.7 times more issues. Half of it ships with security holes. Code duplication is through the roof. AI-assisted PRs take four to five times longer to review. The response to...

info_outline
DOP 354: Your Dead Founder Trains New Hires show art DOP 354: Your Dead Founder Trains New Hires

DevOps Paradox

#354: How do you build a consent system for someone who is dead? How do you clone a voice so it cannot be turned into a deep fake? Miles Spencer built a company around those exact questions. Reflekta.ai lets you talk to a reflection of someone who has passed. His own father reads a bedtime story to his granddaughter every night and talks it through until she falls asleep, eight years after he died. Is this just deep fake with better branding? What happens when the AI goes off the rails and asks grandpa for the three numbers on the back of a credit card? Miles has an answer for each one, and...

info_outline
 
More Episodes

#362: Feature flags or canary deployments - do you need both? Viktor puts it to Alex Casalboni from Unleash, who says he argues about this with his colleagues roughly every day, and the answer lands clean. Switching a hostname, a database, an API vendor? That is infrastructure, nothing to do with who the user is, so keep your canaries and your blue-green. But a canary switches one thing at a time. Try running three A/B tests and ten behavioral changes through it and the whole approach buckles. Anything that needs to know who the user is belongs in a flag. Different layers of the stack, different tools, and most teams will end up with both whether they planned to or not.

Back up, though, because there is a new word attached to all of this. FeatureOps. There is a manifesto and everything, sitting at [featureops.io](https://featureops.io/), reading a lot like someone nailed 95 theses about feature flags to a door. Real discipline, or marketing wrapper? Alex gets about ten seconds of pleasantries before he has to answer for the word. His defense is narrower than the name suggests, and better for it: every ops discipline we have gets you to the deployment and then waves goodbye. Something breaks, you go around the whole loop again - hotfix, pipeline, 20 or 30 or 60 minutes, fingers crossed. FeatureOps is the claim that the same principles apply after the code is already running. Runtime control. Alex says enterprise customers routinely have a 12 to 24-hour round trip between finding a problem and getting the fix live. Even for a hotfix.

Viktor is not letting the seconds claim through unchallenged. If it takes you a day to notice and two seconds to flip, that is a day and two seconds - so stop measuring from the convenient starting line. Alex concedes the framing and then goes somewhere better with it: the bottleneck was never the clicking. It is the humans and the bureaucracy in between. Which is why Unleash is pushing impact metrics, where the SDK sends error rates back and the system kills the feature itself, no human in the loop. Then Darin calls BS on immutable event log, because there is no such thing as immutable data, and Alex takes the hit cleanly - fair, it is append-only with locked-down keys, not magic.

Nobody puts this part on a landing page. Flag evaluation has an input, not just a true/false output, and that input is user context - which means an external API call is not just latency, it is your PII leaving the perimeter. A compliance problem hiding inside a performance decision. And the flag graveyard is worse than you think: companies create roughly ten flags for every one they clean up, and Alex has a customer whose oldest flag dates to 2012. His fix is an MCP server that opens the cleanup PR for you when you mark a release complete. Best line of the day, on whether flags complicate your code: everything complicates your code, and the best way to not complicate your code is to not code.

 

Alex's contact information:

LinkedIn: https://www.linkedin.com/in/alexcasalboni/

X: https://x.com/alex_casalboni

 

YouTube channel:

https://youtube.com/devopsparadox

 

Review the podcast on Apple Podcasts:

https://www.devopsparadox.com/review-podcast/

 

Slack:

https://www.devopsparadox.com/slack/

 

Connect with us at:

https://www.devopsparadox.com/contact/