Rolling Deployments
Rolling Deployments
Rolling Deployment is one of the most straightforward deployment tactics that is a delight to use. Only because it is so straightforward and affordable makes it the most widely used deployment approach. This is the standard deployment approach used by the majority of tools.
We slowly replace older versions of the application with the new one as part of rolling deployments by replacing the supporting infrastructure.
For instance, in kubernetes containers, the operating service is replaced with a newer version of the code or artifact, or in an EC2 machine, the previous services are now running on a newer version of code or artifact.
Note: The infrastructure replacements take place as incoming requests are processed gradually rather than all at once.
As the Rolling Deployments are incremental, some servers would serve the new version of the artefact at the moment of deployment while others would provide the older versions.
As a result, the answer would be created using the appropriate version depending on which server receives the request. Because of this, backward and forward compatibility become essential features.
How to apply the Rolling Deploy method..?
The practise of rolling out is usually graceful.
- Pick a server for deployment.
- Stop in-coming traffic to it. -- Remove it form load balancer.
- Wait for existing request to be completed.
- If no Infra replacement. -- pull the latest code/artifact. -- Restart the process.
- If Infra replacement. -- Terminate the server -- create the new server with new code or artifact
- Attach the server with load balancer.
Tuning the Rolling Deployment
- Concurrent Server -- We can choose 'n' servers concurrently rather than selecting one server for upgrade at a time. -- This will seed-up the deployment. Note: 'n' shouldn't be excessively big or little.
- Double- Half Deployment.
The infrastructure is often doubled with new code before being restored to its original capacity in rolling deployment.
Note: Make sure your database cache can handle a lot of connection queries while doing this.
- Terminate one and Spin one.
Pros of Adopting Rolling Deployment
- Much faster then Blue Green deployment.
- Deployment ensures zero downtime.
- Rollouts are gradual.
- Any defect affect only a small set of user or requests.
- Cost efficient deployment strategy.
Cons of Adopting Rolling Deployment
- No Environment isolation between the old and new servers.
- Changes we rollout has to be backward compatible.
- Changes we rollout has to be forward compatible.
- Deployments takes a long time to complete.
- Stateful applications will be affected during the deployments.
Note: These are merely my personal worries, not the main problem.💡