Blue-Green vs Canary Deployment
Blue-Green Deployment
Blue Green is a deployment pattern that reduces downtime by running two identical production environment called blue and green. Only one environment lives at a time.
We need to ensure about the changes. Changes must be forward and backward compatible. We need to setup a parallel infrastructure i.e. same number of servers and services used in the actual infrastructure. Post the setup deploy the new version to the new infrastructure, do the sanity and validate everything. Then switch all the traffic to the green infrastructure. After everything is validated, remove or stop the old infrastructure (blue).
Pros of Blue-Green Deployment
- Rollbacks are superfast and simple, rollbacks to the previous change are just a route change.
- Downtime during deployments is minimized, with no period where no request could be served.
- Deployments are quick, just a flip of a switch.
- Disaster recovery plan is super simple.
- Deployments can happen in regular hours.
- We can debug why a release failed.
Challenges in Blue-Green Deployment
- During deployments, the infra cost would be double.
- Stateful applications would face problems. The information stored on instances like cached files, and artifacts will be lost when we switch from blue to green, everything would need to be rebuilt.
- Database migrations are tough.
- Frontend and Backend compatibility for APIs.
- Blue Green Setup takes effort and time.
Canary Deployment
Canary deployment is a pattern that allows us to roll out code, features, and changes to an initial subset of users/servers. Basically, the change is deployed to a small subset of servers, then tested and rolled out to the rest of the servers. If everything is good then only roll out to all the servers otherwise rollback it. So canary deployment act as an early warning indicator so that we could avoid a massive outage.
We create a small parallel Infra. We need to deploy the new version to one server and then monitor the vitals, cpu ram, error rates, and all. Test all the changes. If everything is working as expected then deploy this to the remaining servers as well.
In canary deployment, the selection criteria of new version traffic can be different i.e geographical-based, random users, beta users, internal employees, etc. Canary deployment is very helpful when you re-wrote your service.
Pros of Canary Deployment
- It allows us to test the changes in prod with actual users.
- Rollbacks are much faster because we deployed on few servers.
- If the newly deployed version of code has bugs it would affect a very limited set of requests.
- Zero downtime deployments.
- We could deploy even when we are unsure about the new release.
Challenges in Canary Deployment
- Engineers will be habituated to test in prod directly which is not a recommendable practice.
- Architecting a canary deployment is complex.
- Parallel monitoring setup observability is super important in canary setup side-by-side comparison of vitals, cpu ram, response times, error rates, exceptions, etc.
That’s all about Blue-Green and Canary Deployments. Read more in-depth and choose which type of deployment you can use according to your project’s requirements.
