What is Blue/Green deployment strategy?
In very short: release a new version alongside the old version then switch traffic.
In blue/green deployment, a new version of application instances denoted by green version is deployed along with the previous version of application instances denoted by blue version.
Traffic is routed to the blue deployment while the green deployment is created and tested. After you’re finished testing, you route traffic to the new version.
After the deployment succeeds, you can either keep the blue deployment for a possible rollback or decommission it.
What are key benefits of blue/green deployment strategy?
Here they are:
- Zero downtime.
- Instant rollback. You can roll back at any time during the deployment process by adjusting the load balancer to direct traffic back to the blue environment.
- Environment separation. Blue/green deployment ensures that spinning up a parallel green environment doesn’t affect resources that support the blue environment. This separation reduces your deployment risk.
What are key points to consider when going ahead with blue/green deployment strategy?
- Cost and operational overhead: Remember you have to maintain duplicate environments with same infrastructure, so of course cost and operational overheads will be there.
- Backward compatibility. Blue and green deployments can share data points and datastores. You need to ensure that both versions of the application can use the schema of the datastore and the format of the records. This backward compatibility is necessary if you want to switch seamlessly between the two versions if you need to roll back.
- Connection draining: To switch from one version to another you need to have connection draining in place.
- Session availability: If the application requires session persistence, you as a application owner should have: Support for session sharing between application servers through session replication or using a datastore. This way even after switch over to green version, users sessions will be available.