Software Development Updates

In the past, new software version deployments were mostly scheduled at night to reduce user disruption. But in the age of cloud-based environments, deployments are more challenging because users expect the availability of websites or software in all time zones, 24/7 which complicates the scheduling of updates.

Releasing regular software updates is an important undertaking of custom software development. You have to make sure that the product works up to expectations, that there isn’t any issue with its performance or functionality, and that it offers an amazing user experience. But none of this can happen if your application deployment fails because of impending risks like facing downtime.

Fortunately, you can minimize the risks and almost eliminate the downtime, if you adopt the canary or blue-green deployment strategies. These deployment strategies are so popular that often expert developers are seen engaging in a debate of canary vs blue-green deployment. 

Let us explore these deployment strategies, their working, advantages, and disadvantages. Such an analysis is critical to make an informed decision about picking the right strategy for deployment purposes. 

1. What is Canary Deployment?

Canary deployment is a method where you release your software applications for a selected group of people before you launch it for the entire user base. It is a useful way to test out the new version, update, or feature in a real-world setting with real users. 

The small subset of users or servers that utilize your new release before the official launch is called a Canary group. They use your software applications and offer valuable feedback. This helps find and fix unanticipated bugs and issues like downtime. 

Canary deployment ensures a seamless launch of your software system.

1.1 How does Canary Deployments Work?

In a canary deployment setting, two different versions of the same software are run together. The old version is called “stable”, whereas the new version is called “canary”. The canary deployment is implemented as shown in the following steps:

1. Initialization: Normally, all your traffic goes to the stable version. To test the canary version, you have to divert a small subset of your traffic, let’s say 5% of your total traffic to it.
2. Canary Release: Now, only 5% of your live users will be able to see and use this new version of your application. The rest of your users will continue to use the stable version without any interruptions. 
3. Monitor Performance: With a small audience using the Canary release, you can perform various tests to find out if there are any issues with the new version. 
4. Rollback: If you find a problem with the new version, just switch back to the stable version. It won’t have any considerable impact on your users. 
5. Increase Traffic: If you are satisfied with the results, then gradually increase the traffic to the canary and repeat the tests to verify its performance. For example, go from 5% to 10%, then 25%, 50%, 75% and lastly 100%. 
6. Complete Deployment: Discard the old stable version if you are getting satisfactory results with 100% of traffic diverted to the Canary version. Your canary version becomes your new stable version.

1.2 Advantages of Canary Deployment

• Cost-effective: Canary release isn’t costly because it doesn’t require you to create a duplicate environment. 
• A/B Testing: You can leverage canary deployments to prepare two groups of users and present them with two different versions to see which one works well. 
• Capacity Test: Canary deployments have a capacity test by default. You can easily detect the performance issues as you gradually migrate more users to the canary. 
• Early Detection of Issues: Canary helps you identify bugs and issues before the new version is released for the entire user base. 
• Faster Deployment: Canary allows you to quickly deploy the latest feature or upgrade to a small percentage of users. You can fix the problems as you migrate more users over to the Canary release. 
• Feedback: In this deployment strategy, you launch the new version for a targeted group. They use it and provide valuable feedback which can be used to perfect the product and make it available for everyone to use. 
• No Downtime: When used by a small number of users, the canary doesn’t experience downtime. 
• Easy Rollback: In case of failure or a problem, the canary can be easily rolled back and servers can be restored to the previous version.

1.3 Disadvantages of Canary Deployments

• Added Complexity: During the canary release, the team must be prepared to handle additional components, codes, and services. It is also difficult to handle multiple APIs and database schemas. 
• Software Deployed on Customer Devices: In such cases too it is complicated to handle canary. It would take time to make sure that the customers have updated and evaluated the software on their devices.
• Script Testing: In comparison of canary vs blue-green deployment it is very challenging to script canary deployment. A lot of time will be consumed after human verification and testing. Moreover, you would need to do more research for instrumentation and monitoring in the product testing. 
• Time: Setting up a pipeline for canary deployment is time-consuming.

2. What is Blue-Green Deployment?

Blue Green deployment needs two production environments where the older or active environment is referred to as blue and the new or inactive environment is called green. 

Both environments will be identical. It doesn’t experience any downtime when you upgrade your app in the production environment. You will have to deploy your new code or changes to the green environment where it will be thoroughly tested. 

Once they are confirmed to have been working up to expectations, the router will switch to the environment where the changes were deployed. It will be a smooth transition. 

In the blue-green deployment, you will have two copies of your app, the blue is the production version and the green is the upgraded version. You have to assign a few of your servers to deploy the green version while the remaining servers run the blue version. 

After deploying, testing, and verifying the performance of the green version, you can gradually shift all your traffic from the blue to the green version. Starting with let’s say, 20% traffic and then gradually diverting more and more traffic to the inactive or green environment will also help you track if any issues arise. 

When the issue arises, you can divert all your traffic back to the active or blue environment. The blue-green deployment is also popularly known as the zero downtime deployment strategy.

2.1 How does a Blue/Green Deployment Process Work?

Before getting started with the blue-green deployment, you would need a service mesh, a load balancer, and a router for switching the traffic. The blue-green method includes the following stages of software deployment: 

1. Deploy New Version: Simultaneous with the blue version, release the new green version in an identical production environment. Test if it works as per expectations. If needed, make necessary changes. 
2. Switching Traffic: After the green version passes the tests, start gradually rolling the traffic to the green from the blue environment. It should be done smoothly and shouldn’t interrupt end users. 
3. Monitor: Monitor all the user interactions with the new green version. Watch closely for potential issues and errors. 
4. Deploy or Rollback: If any problem arises, switch back to the first version immediately. Otherwise, switch all the traffic from blue to green. Now, the green version will be your new blue or current version.

2.2 Advantages of Blue-Green Deployment

• Zero Downtime: When you deploy new versions using the blue/green method, there is zero downtime. It means that if any problem arises at the time of deployment, your users won’t be affected by it. 
• Easy Rollback: It is very easy to roll back to the previous blue version if any errors are found with the new green version. It also helps you respond quickly to the issues. 
• Reduced Risk: During the blue/green deployment, the risks of data loss and service disruption are minimal. 
• Production-like Testing: The blue-green deployment strategy has two identical production environments. This enables you to test your new version in a real environment. 
• Scalability: As per the requirements, you can easily scale up or down the deployment.

2.3 Disadvantages of Blue/Green Deployment

• Setup Time and Effort: Setting up a new or green environment takes time and effort. It is risky and complicated. However, certain software deployment tools offer in-built functionality to deploy blue-green production environments. 
• Cold Starts: At the switching point from one environment to another, users can experience performance and other unexpected issues. This can be solved with regular stress testing and warm-up routines.
• Cost: When you duplicate the active production environment, you have to double down the purchase of equipment and necessary resources. 
• Schema Migration: Migrating the database is quite challenging. Blue/green deployment doesn’t support changes in a database schema. Even when the schema doesn’t change, it is hard to sync the data. Making the database read-only and using replication are common practices to make the transition smooth.
• User Transactions: All transactions are aborted when the traffic is shifted from one environment to another. To manage this situation, error messages are displayed on users’ screens and they are asked to retry the transaction. In truth, this results in a poor user experience.
• Shared Services: If the app depends on a third party, external database, or any other legacy service then there is a possibility of information leaking during blue-green deployment. In any case, if one production environment is affected by another, the deployment will be interrupted and the tests will become unreliable.

3. Canary vs Blue-Green Deployment – Which is Best for You?

Let’s have a look at the tabular comparison of canary vs blue-green deployment.

	Canary Deployment	Blue-Green Deployment
1.	Releases the new version to a small set of users or canary groups.	Maintains two identical production environments where one is active and another is inactive. The new version is released in an inactive or green environment.
2.	Before rolling out to a larger audience, the performance is monitored and user feedback is taken into consideration.	The traffic is diverted to the inactive environment gradually until the new version is deployed completely.
3.	The impact is less when an issue arises before the rollout is completed.	If any issue arises, blue-green deployments minimize downtime and rollback quickly.
4.	Ideal deployment method to minimize the risks and test drive new features.	Useful for addressing performance issues and disaster recovery situations.
5.	Works with limited resources with a controlled and interactive approach to risk management.	Works with a significant amount of resources to maintain two identical environments. Helps thoroughly test and validate new features and version releases.

4. Conclusion

Blue-green and canary deployments are popular and proven strategies. Both help in minimizing downtime and other risks. Comparing Canary vs blue-green deployment in this article has made one thing clear: the canary is more suitable for reducing the risks and testing new features. Meanwhile, blue-green is more suitable for reducing downtime and quick rollbacks.