Canary deployment is the process of releasing software in multiple stages. Unlike traditional release methods, it’s a good way of releasing software and has lesser negative impacts on releases. In this process, the software is rolled out into small parts to some users in the initial stage. It lets organizations test in the real-world environment and receive feedback. Once the users accept the changes, the update is rolled out to the rest of the users.
With Canary deployments, you can see how users interact with application changes in the real world. Compared to blue-green deployments, the canary strategy offers no downtime, easy upgrades, and rollbacks. Canary deployments are smoother, and even if the deployment fails, the magnitude of impact remains limited.
How Does Canary Deployment Work?
In canary deployment, two versions of the application run simultaneously. The old version is called “the stable”, and the new one is “the canary”. Now you can use two ways to deploy the update: rolling deployments and side-by-side deployments.
| Rolling Deployments | Side by Side Deployments |
|---|---|
| 1. You install the changes in waves or stages using a few machines at a time. The others continue running the stable version. | 1.The side-by-side strategy has a lot in common with blue-green deployments. Rather than upgrading the machines in stages, you create a duplicate environment and install the canary version there. Suppose the application runs on multiple machines or containers, a few services, and a database. |
| 2. Few users start seeing updates while the canary runs on one server. | 2. You clone the hardware resources and install the updates. Once the canary runs on the new environment, you show it to a portion of the user base using a router, a load balancer, a reverse proxy, or some other business logic in the application. |
| 3. When all this happens, you watch how the upgraded machines are doing, errors and performance problems, and listen for user feedback. | 3. 5% of the users are sent to the canary version, and you monitor the canary while gradually migrating more and more users away from the control version. The process continues until a problem is detected or all users come to the canary. |
| 4. As your confidence grows in the canary, you continue to install it on the rest of the machines until they all run the latest release. If you detect a failure or get disappointing results, you can undo the change by rolling back the upgraded servers to their initial state. | 4. After the deployment, the control environment is removed to free up resources, and the canary version becomes the new stable. |
What Are the Different Stages of Canary Deployment?
In a simple structure, the canary deployment has three stages.
- Plan and Create: In the first step, you must create a new canary infrastructure where the latest update is deployed. A small portion of users is directed toward the canary instance, and the rest of the users continue to use the baseline instance.
- Analyze: As soon as some traffic is diverted to the canary instance, the team starts to collect crucial data, including metrics, logs, network traffic monitoring information, synthetic transaction monitoring results, etc. All this analysis is done to check whether the new canary instance is operating rightly. Further, the team analyzes this data and compares it against the baseline version.
- Roll: Once the canary analysis is complete, the team decides whether to roll out the release for the rest of the users or roll it back to the previous baseline state. Second phase analysis is handy for choosing between release rollback and rollout.
Benefits of Canary Deployment:
- Zero Production Downtime, Faster Rollback: Since the canary deployment runs for a small subset of users, you require fewer resources in terms of infrastructure. While a blue-green strategy works only in a whole new provisioned environment, the canary requires a small infrastructure in the beginning to deploy your changes and check if your application is meant for the users.
- Less Costly with Small Infra: Since the canary deployment runs for a small subset of users, you require fewer resources in terms of infrastructure. While a blue-green strategy works only in a whole new provisioned environment, the canary requires a small infrastructure, in the beginning, to deploy your changes and check if your application is meant for the users.
- Easy Experiment with New Features: Your organization needs minimal canary deployment resources. This works as a confidence booster for the developers and testers, as they get more space for experimenting with new things. The loss would be negligible if something fails or doesn’t work as expected.
- Works for all Deployment Sizes: Since each canary deployment is smaller in size, it takes minutes to hours to complete. This is a very helpful environment for fast and frequent updates. The shorter deployment cycles reduce the time to market and provide valuable products to the customers. Canary also works well for large and distributed systems.
Disadvantages of Canary Deployment:
- Risky: Usually, the first group using the canary finds the worst bugs. Plus, it can annoy some users once they know about being used for random testing. However, if you still want to persist with canary deployment without frustrating your users, consider starting an opt-in program for users to voluntarily sign up for being the “early adopter” of the new updates.
- Sometimes Costly: Side-by-side deployments prove costly, as you need extra infrastructure. But if you take advantage of the cloud platforms, then you can create and remove resources on demand to keep the costs down.
- Complexity: There are some commonalities between blue-green deployments and canary deployments. For instance, production machines, migrating users, and monitoring the new system are complicated tasks. Instead of performing all these tasks manually, automate the deployment process using a CI/CD platform.
Conclusion:
Downtime, bugs, and issues are a reality; your organization is no exception. But instead of worrying about it, you can change your approach to reduce the impact of bad releases. For instance, in a traditional release approach, you would expose the application to whole users, which involves a risk factor if it has issues.
Contrary, if you would be able to let fewer users – 5%, for example – see new updates of your application, then risk automatically gets low. This approach is known as canary deployment.