Frequent deployment is very common in most of the devops projects. Product or Run team deploy releases to non production and production environments more often rather than long release cycles. With the evaluation of micro-service approach,code is written in more modular way and this is allowing us to deploy changes to different parts of the code base simultaneously.
Key Advantages of shorter development cycles:
Rolling out of new application features and other modifications faster.
Customer feedback is as faster which means the team can incorporate new features and fix problems faster.
With more frequent deployments, challenges for the DevOps team or Operations team to avoid downtime experienced by the end user when a release is being deployed and develop strategies as well to deploy code with minimum risk.
In this blog, I will talk about a few different deployment strategies that will allow your team to work faster and more reliably.
Deploy using immutable infrastructure:
This is a model where we never change any part of your system once it is deployed. If we need to change it, we need to deploy a new system.Deployment should be done by automated deployment pipeline for every part and every layer of your infrastructure.
The most common implementation of the immutable infrastructure paradigm is the immutable server. This means that if a server needs an update or a fix, new servers are deployed instead of updating the ones already in use.So, instead of logging into the server via SSH and updating the software version, every change in the application starts with a software push to the code repository, for example, git push.
Benefits of immutable infrastructure:
• Reduction in configuration drifts: By frequently replacing servers from a base, known and version-controlled configuration, the infrastructure is reset to a known state, avoiding configuration drifts.
• Simplified deployments: Deployments are simplified because they don’t need to support upgrades. Upgrades are just new deployments.
• Reliable atomic deployments: Deployments either complete successfully, or nothing changes. It gives more trust in the deployment process.
• Safer deployments with fast rollback and recovery processes: Deployments are safer because the previous working version is not changed. You can roll back to it if errors are detected.
• Consistent testing and debugging environments: Since all servers use the same image, there are no differences between environments. One build is deployed to multiple environments. It also prevents inconsistent environments and simplifies testing and debugging.
• Increased scalability: Since servers use a base image, are consistent, and repeatable, automatic scaling is trivial.
• Simplified tool-chain: The tool-chain is simplified since you can get rid of configuration management tools managing production software upgrades.
• Increased security: By denying all changes to servers, you can disable SSH on instances and remove keys. This reduces the attack vector, improving your organization’s security posture.
We can use either canary or blue/green deployment when deploying applications in immutable infrastructures.
What is Blue Green deployment?
Blue/green deployments are a type of immutable deployment used to deploy software updates with less risk by creating two separate environments, blue and green. “Blue” is the current running version of your application and “green” is the new version of your application you will deploy.
This type of deployment gives you an opportunity to test features in the green environment without impacting the current running version of your application. When you’re satisfied that the green version is working properly, you can gradually reroute the traffic from the old blue environment to the new green environment by modifying DNS. By following this method, you can update and roll back features with near zero downtime.
In a blue-green deployment, both systems use the same database back end.Databases can often be a challenge with this technique, particularly when you need to change the schema to support a new version of the software. The trick is to separate the deployment of schema changes from application upgrades. So first apply a database change to update the schema to support both the new and old version of the application, deploy that, check everything is working fine so you have a rollback point, then deploy the new version of the application.
Another way is to use of mirrored database.We can use the primary database by blue for write operations and use the secondary by green for read operations. During switchover from blue to green, the database is failed over from primary to secondary. If green also needs to write data during testing, the databases can be in bidirectional replication.
Blue-green deployments depend on traffic routing and can be done by updating DNS CNAMES for hosts. Long TTL values can delay these changes and in that case,we can change the load balancer settings so the changes take effect immediately.
Blue Green Deployment Implementation:
Benefit of Blue Green Deployment:
Limiting the downtime compared to traditional application deployment.
Ease of rolling back deployments.
Canary Deployment:
Canary deployment is the practice of directing a small number of your customers to the new version, usually running on a single service instance (the canary). You then deeply scrutinize any behavior changes or errors that are generated. You can remove traffic from the canary if you encounter critical problems and send the users back to the previous version. If the deployment is successful, you can continue to deploy at your desired velocity, while monitoring the changes for errors, until you are fully deployed.
Canary Deployment Implementation:
Source: https://martinfowler.com/
Benefit & Drawback of Canary Deployment:
Less impact of a faulty release on the customers.
More control for the development team during deployment. Since the impact to the customer base is relatively small, the development team can either work to fix the issue or simply abandon the deployment.
One drawback of using canary releases is that you have to manage multiple versions of your software at once.
Some other popular Deployment strategies:
Rolling Deployment:
Rolling deployments update large environments a few nodes at a time. The setup for rolling deployments can be similar to blue-green deployments, but this time with a single logical environment. The environment can have many nodes.In a rolling deployment, an application’s new version gradually replaces the old one.
"Big Bang" Deployment
, A big-bang deployment seems to be the natural thing to do,the full solution is developed and tested and then replaces the current system at once.Big bang deployments required the business to conduct extensive development and testing before release, often associated with the "waterfall model" of large sequential releases.It is a less agile for modern teams.
Conclusion:
Regardless the deployment strategy ( either blue green or canary), devops team should follow number of best practices like Continuous Integration/Delivery, use of build automation tool like Terraform or Cloudformation to build the environment,use of configuration management tools like Ansible or Puppet and automated process of notifying concerned teams on failure to keep deployment risk minimum. Post deployment monitoring is important as well and should be part of process visibility of all the post-deployment issues among Operations / DevOps teams and developers and allows the teams to be more collaborative and responsive.
Comments