Ever ran into a situation when you have to deploy changes to the production server and you are waiting for that perfect time when there are no active users using the tool? Don’t get me wrong, this could work, in-fact this is how we work most of the time but say your application is used across the globe. Now, when will they all sleep? Now, we are into a problem we cannot stop the service just like that and expect nothing happens. Okay, let’s say we have four instances of the application running. Now, we could take two out of the four to deploy the latest changes and once it’s up we take the other two with the new changes. This is sort of how we could fix the problem. But, picture this, if you take out two of the nodes the overall traffic you are experiencing on the site could not be served by the remaining two of them. So, what do we do now? This is where the Blue/Green deployment comes into play.
What/How?
You might have already guessed how we are going to solve this problem? Don’t blame the spoiler animation. When deploying to the production server for the first time, we need to deploy an extra identical production setup. The load balancer at that time will point to the Blue deployment at first. You will start deploying onto the Green setup and once this is up the load balancer will pick up this one to route the traffic to. Looks like a lot of manual work in here. But, we could do this automagically depending upon how your deployment is running. May be your deployment is running by reverse proxy/load balancer created with nginx or could be running on containers orchestrated by Kubernetes, we could come up with the auto switching solution. The main idea of switching to the updated deployment is that there should be some kind of communication to know that new changes are up and running to serve the traffic. In case of nginx, you could do with something like this. If the deployment is modern and running on containers; you could make leverage of Istio. Check out this for further read.