An in-depth introduction to Blue Green Deployments
Blue Green Deployment is a deployment pattern that reduces the downtime during deployment by running two identical production setups called - Blue and Green.
During deployment when we reboot the API servers there are chances that the incoming request fail because the server is unresponsive for a short period. Also, it might happen that the release had a major bug and we need a quick rollback.
How can we achieve both of them in one shot? The answer is Blue Green Deployment.
Implemention
Blue Green deployment is implemented by having a separate fleet of infrastructure for the old version - Blue and the new version - Green. The new infrastructure is identical to the old one.
The deployment flow
the new deployment artifact is tested and kept ready to be deployed
a parallel infrastructure is set up identical to the existing
the new version is deployed on the new fleet - Green
the correctness of the setup is validated
the proxy is re-configured to now forward 100% of traffic from the Blue (old) setup to the Green (new) setup
a final sanity test is run on the new fleet
the blue fleet is now shut down
Pros of Blue Green Deployment
rollbacks are just a config change and hence quick
downtime during deployment is minimal
deployment is just a flip of a switch
disaster recovery is simple given we already have the automation to build a parallel setup
deployments can now happen during the working hours
debugging a failed deployment is simple as we have the infrastructure with the debug information handy
Possible challenges
during the deployment the infrastructure cost shoots 2x
the stateful application would need to rebuild the state on new servers
the database would have to be shared between the fleets
any schema migration on the database needs to be backward and forward compatible
the API responses have to be forward and backward compatible
setting up this deployment strategy for the first time is difficult
When to use Blue Green Deployment?
when you need zero downtime deployment
your infrastructure can tolerate 100% traffic switch
you can bear the 2x cost of infrastructure during deployment
Points to remember
have a solid automation test suite to validate the correctness
ensure forward and backward compatibility of API and schema changes
infra cost will shoot up hence minimizing the time for which you are running 2x infra
Here's the video of my explaining this in-depth 👇 do check it out
Deployments are a pain if we are unsure about our release changes. But sometimes even if we know our changes well, something weird could happen in the infra that would fail your deployment and put your infra in an inconsistent state.
So, is there a way to address this? What if we have a place to deploy our changes and validate them before they hit production; and have a quick way to roll back if something goes wrong?
This is the core idea behind a Blue-Green Deployment
In this video, we take an in-depth look into a blue-green deployment pattern, understand why we need them, what problem it addresses, learn how they are implemented, talk about its benefits and challenges, and conclude with some points to remember when you adopt this deployment pattern.
Outline:
00:00 Agenda
03:13 An introduction to Blue-Green Deployments
06:36 Why do we need Blue-Green Deployments
09:12 How Blue-Green Deployment is implemented?
13:26 Pros of having a Blue-Green Deployment
19:49 Challenges in having a Blue-Green Deployment
25:36 When to use Blue Green Deployments
26:39 Key points to remember while adopting Blue Green Deployment
You can also
Subscribe to the YT Channel Asli Engineering
Listen to this on the go on Spotify
Thank you so much for reading 🖖 If you found this helpful, do spread the word about it on social media; it would mean the world to me.
You can also follow me on your favourite social media LinkedIn, and Twitter.
Yours truly,
Arpit
arpitbhayani.me
Until next time, stay awesome :)