A company wants to deploy a new version of a product recommendation model to production. To minimize the risk of a bad model impacting the entire user base, they direct a small percentage of incoming production traffic to the new model while the rest continues to use the stable version. What type of deployment strategy does this represent?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Ever wonder where the term 'canary' comes from? Back in the day, coal miners would carry a canary down into the tunnels. If there were toxic gases, the canary would get sick first, giving the miners a warning to get out. In MLOps, we do the exact same thing with our models! When you've got a brand new, shiny model version, you don't just dump it on all your users at once—that's a great way to trigger office riots if something goes wrong. Instead, you route just a tiny sliver of traffic, maybe 1% or 5%, to the new model. You monitor it closely to see if it behaves. If it does, you gradually ramp up the traffic. If it crashes or starts making wild predictions, you pull it back immediately before anyone else notices. It's a lifesaver in production!
Full explanation below image
Full Explanation
Canary deployment is a progressive delivery strategy where a new version of an application or machine learning model is rolled out to a small, select subset of users or traffic before being made available to the entire infrastructure. This strategy serves as an early warning system to detect potential issues (such as runtime errors, latency spikes, or poor prediction quality) in a live production environment with minimal blast radius.
Here is how canary deployment compares to other strategies: 1. Canary Deployment: Traffic is split dynamically (e.g., 95% to the old version, 5% to the new version). If key performance indicators (KPIs) remain stable, the new version is progressively scaled up to 100%. 2. Blue-Green Deployment: Two identical production environments (Blue representing current, Green representing new) run simultaneously. Once the new model in Green is fully validated, traffic is cut over all at once from Blue to Green. While safe, it requires double the resources. 3. Shadow Deployment: The new model receives all production traffic in parallel with the active model, but its outputs are not served to the end user. This allows testing with real-world inputs without any risk to user experience, but it increases computational overhead. 4. Rolling Deployment: Replaces instances of the old model with the new model gradually across the server fleet until all instances are updated.
Canary deployments are highly favored in MLOps because they allow teams to validate model performance and user behavior metrics under real-world conditions without risking service-wide disruption.