Feature Flags vs Canary Deployments

**Alex Casalboni** (0:00)
So it's more of a configuration management problem in that context. And that doesn't really give you what I was referring to before as far as runtime control and being able to flip a flag in production in seconds. If flipping a flag still requires a full CI-CD pipeline and a full redeployment, is it really a feature flag? In our opinionated view as an unleash, we don't think that's the way to use feature flags because it's more like an environment variable.
That you can configure the application with it at startup time and that's it.

**Darin Pope** (0:34)
This is DevOps Paradox, episode number 362, feature flags versus canary deployments.
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can and mix it with random buzzwords like Kubernetes, serverless, CICD, team productivity, islands of happiness, and other fancy expressions that make us sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often since they might make us look incompetent. The truth is out there and there is no way we are going to find it.
Yes, it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farsi. There's a new word floating around. We've got new words floating around all the time. This one is FeatureOps. At least they didn't try to make it DevSecFinFeatureOps, because that would have just been more silly. Is FeatureOps really a real discipline or not? Or is it just a marketing wrapper around yet another thing? Today we're going to be talking with Alex Casalboni from Unleash. Alex, how are you doing?

**Alex Casalboni** (2:02)
Hey, guys. Glad to be here. Thanks for inviting. And yeah, let's talk about FeatureOps today.

**Darin Pope** (2:06)
Let's talk about FeatureOps, because there is a site for FeatureOps, and we'll go ahead and tell you upfront, because it's featureops.io.
It feels very agile manifesto to me. Is that sort of what you were going for? Is like, here are the 95 theses of how features should be used?

**Alex Casalboni** (2:24)
Pretty much. That's based on what we see with many of our customers, but also many of the experience of the founders of Unleash and many other people that work at Unleash today. And the main point is to be super vendor neutral, super irreferenceable, because it's a problem that basically every company has, whether you are in a financial industry or a big retailer or whatever you're doing, managing feature management and release management is a big problem. And handling that when you have a thousand engineers across 25 teams at scale, and especially when if you're down for an hour, it's millions of dollars and reputational damage and all those issues. You know, how do you handle this process at scale? That's what the manifesto is for, really.

**Viktor Farcic** (3:14)
I feel that we need to backtrack for a moment for this FeatureOps, because I was before you started speaking, I was imagining my PRDs that I passed to my agent. This is the feature I want. I'm assuming that's not where this is going.

**Alex Casalboni** (3:29)
Yeah, let's do a step back. Let's take a step back. I think the main first of all, why Ops? Because there are some operations involved, and most of the other discipline like DevOps and all the cousins pretty much help you until the deployment. You can do all the things in the local environments. You can do all the RCI, CD. You can do all the static check and all the GitOps magic to make sure the environment is aligned to your configuration, blah, blah, blah. But basically, a lot of the 90% of the approaches, you ship to production.
And then if something happens in the production environment, you need to go through another cycle of that. You need to go through a hotfix. You need to go through another CI, CD pipeline, running for 20, 30, 60 minutes, it depends.
And so what the FeatureOps methodology is trying to address is can you apply the same principles, but after the deployment is done, when the application is running in production? And the better term to understand what I mean is a runtime control. Can you change application behavior at runtime in production to reduce the blast radius of an incident? Things like a kill switch, things like something that you can enable or disable or change the behavior in seconds instead of waiting for a patch from the development team and then a full CI-CD pipeline running for half an hour, and then you get the fix in production. That's like the main reasoning behind Core.