As a software developer who constantly deploy new codes to the server, you must know how the server is migrating from old code to your newly deployed code and how the users are served during the migration. Here are 5 deployment strategies that software developers use –
1. Big Bang Deployment
In this, we directly deploy the changes to all the servers at one like a big bang (bulk) deployment. If there are 4 servers which are running old code, new code will be deployed on all 4 of them simultaneously. While the instances are updating the change, there is downtime and users will face outage. Sometimes, this technique becomes our compulsion incase of immediate package version upgrade or ad-hoc tasks.
2. Rolling Deployment
In this case, instead of big bang, we deploy the changes to one of the servers first and verify the changes. If 4 instances are running on older code, new code will be deployed to only 1 of the instances and rest 3 of them will run on older code. Once we are sure that the new instance is working correctly, we gradually “roll-out” the changes to other instances too. Some points to note on Rolling deployment :
- While rolling deployment seamless, one of the problem is that it is not a targeted deployment. It means that when we have deployed our changes to 1 instance, we cannot control the user traffic to use rest of the 3 and target only small percentage on that 1 instance. So, if say out of 100 users requests, 80 requests reach older 3 instances, they would not face the outage, but if the new instance is having some issue, then remaining 20 requests going to 1 instance will be throwing error.
- If the new change is successful, then this technique has minimal downtime.
3. Blue/Green Deployment
In this case, we maintain an copy of the production environment separately which does not serve live traffic. So if production environment P with 4 servers is serving the traffic, there will be a copy of the production environment say Q also with 4 servers. The actual production environment is called “blue” environment and the replica is called “green” environment.
The purpose of the green environment is use it as a play-ground for UAT or QA testing while mimicking the production environment. In case of blue/green deployment, the changes are first deployed to the green environment and tested thoroughly. Once the changes are tested successfully in green environment, the load balancer switches to the servers in the green environment thereby making it the “blue” environment now. The earlier blue environment becomes idle.
The best part about this deployment technique, is zero downtime. The traffic switch is seamless and easy. In case something goes wrong, we switch back to the older blue environment.
The problem, though, is that again this is not a targeted deployment meaning the entire traffic is switched from blue to green at once.
Another problem is cost and maintainability. Maintaining a replica environment of production doubles the cost and dev efforts.
4. Canary Deployment
This deployment named after the age-old use case of “Canary Bird”. The coal miners in earlier times used canary bird in the mines to detect dangerous gases, if they would find the bird to be distressed, they would evacuate the mines to preempt the possibility of dangerous gases.
In this deployment we either direct 1% (or some %) of traffic (our canaries) to the new servers or we choose only a subset of servers to deploy the change to. It is very much like deploying to real-world but on a very small scale. We can even decide to deploy on geographical location. Let’s say a new feature is launched only in Asia to test the waters whether it is works or not.
This time it is a targeted deployment because we can target the users who will get to use the new changes. The problem with canary deployment is maintainability.
Generally canary deployment is used along with rolling deployment.
5. Feature Toggle Deployment
This is a deployment technique in which we handle the control of servers toggling from old to new and new to old versions. We maintain a switch (a toggle) which switched on, the servers respond with new changes and when switched off, they respond back like older version. In this deployment all servers behave together like new servers or old servers.
Feature Toggle Deployment can work together with above deployment techniques as well.
Out of all, most widely used deployment technique is Blue/Green due to its simplicity and zero-downtime advantage.
References:
https://www.youtube.com/watch?v=AWVTKBUnoIg