What is your deployment strategy?

In the DevOps life cycle, deployment is a main phase. We are using many strategies to deploy our software artifacts in the production environment. In this blog, I am going to discuss application deployment strategies. From the application deployment strategies bucket list, I have selected basic, rolling, blue-green and canary deployment strategies for today’s discussion.

Basic Deployment

In this strategy, we roll out our new application version for all nodes in the cluster at the same time. Therefore this strategy doesn’t guarantee outage-proof deployment. Services in the cluster will be unavailable for end users for several seconds, minutes or some time hours depending on the amount of changes we are going to roll-out with the new version. This strategy is simple, fast and cheap. But this is the riskiest strategy, because you can’t guarantee the new version of the application will be up and running without errors. So your live users will be unhappy due to lengthy service outages or by seeing failures in the system. If we need to rollback the deployment, it will also take time. This strategy is not recommended to use in production environments. You can use this strategy in lower environments during off hours.

Rolling Deployment

In this strategy, we are incrementally updating cluster nodes with the new application version. You can decide your own batch size to update at once. When the first batch is updated without errors, we will update the next batch. We will continue this until all nodes are updated successfully. If there is a failure in the first batch we can immediately rollback the deployment to the previous version. This strategy is less risky than a basic deployment strategy.

Blue-Green Deployment

In this strategy, we maintain two identical environments as blue and green. Type of the separation between two identical environments will depend on your business scenario. In the most general way servers, virtual machines, file shares and databases will be duplicated between two environments. Or sometimes the separation can be done using namespaces in a kubernetes cluster. Some resources like databases can be shared between two environments. It’s up to you to decide the type of separation you are going to maintain with your business scenario. In the most general form, blue green is duplicating every resource your application depends on. And your setup should have a mechanism to switch traffic between two environments. It can be a load balancer , a reverse proxy or a cloud solution.

At any given time only one environment will serve live traffic. Say the blue is serving live traffic, then you can deploy the next version of the application into the green environment and test it thoroughly. At this point blue is your production environment and green is your staging environment.

If green deployment works well, you can switch live traffic to green deployment.

By using this strategy, we can seamlessly deploy our applications into the production environment. Rollback in this strategy is very simple, you just need to switch the traffic to the environment with the previous application version. If you adapt to this strategy, the live users will be happy due to the minimum downtime and your deployment team will happily spend off hours and weekends. Cost and implementation complexity are some downsides of this strategy.

Canary Deployment

In this strategy, we are releasing new application versions to users in a more controlled manner than in a blue green deployment. Two versions of the application will run simultaneously. We will distribute live traffic between these two versions of the application. First we will select a small set of live users and route their traffic to the new version of the application. Other users’ traffic will be routed to the old version of the application. Then we will monitor the new application version for errors, performance issues and user feedback. If everything is good, we will increase the weight of the users routed to the new application version. This will continue until we route all the live users to new application version deployment. If we get negative feedback or errors, we can easily rollback the new application version.

When we are planning for a canary we should decide on the following factors.

• How many stages ?
• What is the duration for each stage?
• What metric are we going to monitor in each stage?
• What is the criteria we are going to use to determine the success of stages?
• What is the strategy used to migrate users? Is it random, region wise or early adopters?

Benefits of this deployment includes no downtime, easy rollback , capacity test and no cold start. Downside of canary deployment includes frustration of the first user group using the canary, complexity of implementing the setup, time and cost.

You need to choose your deployment strategy wisely, because it depends on your business scenario. For example, if you are considering more about up-time, accurate test, reliability and your application is mission critical, you can use a blue green deployment strategy in a production environment. But for the same application in a performance testing environment you can use rolling deployment. To decide which to choose, first you need to have a good understanding about the deployment strategies and their pros and cons. Then you need to evaluate those deployment strategies with your business scenario and choose the best option.

All right. That’s it. Hope you have got some idea about various application deployment strategies.