Technology Inside Out!

Index ¦ Archives ¦ Atom ¦ RSS

Blue-Green Deployment

A few glimpse of past reminds us that application deployment on clouds was really a cumbersome task. Not only because the rollback was a pretty much complex operation to carry out, but also, because of huge outage or downtime, which inevitably used to disappoint users. But as we can see nowadays, there are some simpler and more efficient ways to perform the same. We are going to discuss one such technique, that is called "Blue-Green Deployment".

Before we jump on to understand Blue-Green Deployment, let's first discuss some relevant terms in brief.

Deployment:

This term is often get confused with the word "release" due to their versatile usage. Thus, their definition may vary with the context of talk. But here, "release" is just a version number of an application, that always doesn't need to deploy. However, "deployment" is the process of installation and configuration of an application on a targeted hardware.

Downtime or Outage:

This is the period of time in which the system fails or it remains unavailable to reply to client's requests. This is either a manifestation of the system crash or during routine maintenance.

Load Balancer:

This can be a hardware device or a software component. It's main feature is to spread the traffic over the server pool, such that, no server is overly burdened while others remain idle. This can also be used to divert network traffic from one server pool to another. We'll see its usage in blue-green deployment. Elastic load balancing is also available to handle multiple elastic clouds.

Let's understand about Blue-Green Deployment technique now.

Blue-Green Deployment:

This is also known as Red-Black Deployment. This is a technique used in application deployment which reduces the risk of downtime and also facilitates the rollback (moving to the previous state). Let us see how it exactly happens.

Workflow of blue-green deployment using a load balancer:
For this technique, we need 2 identically configured hardware components or server pools. Out of which:-
- one is termed as "blue" that is going to be an active environment
- another one is termed as "green" that would be an idle environment.

Initially, some applications (e.i app1 ver1, app2 ver1) are running in our blue environment. As shown in the picture.

Suppose, now we come up with different versions of applications (i.e. app1 ver2, app2 ver2). We want them to deploy and then test these applications. If everything goes right, we'll use these versions in future, but if not, then we would go for the "rollback".

Let's accomplish this using blue-green deployment:

1. Deploy new versions of application in idle environment
2. Here a testing team may test the working of these new versions.
3. Gradually, using load balancer we start diverting the traffic to this green environment. As shown in the picture. With this live testing is also possible.

4. If now, these versions fail or crash due to any possible reason. We can quickly roll back to the previous versions in the blue environment using the load balancer.
5. If new versions are found to be perfectly interacting with the user's traffic, then this "green" environment is kept to be active and "blue" becomes idle.

After successful blue-green deployment, the idle environment is either used to deploy the next version of the application or is simply destroyed.

Some points to ponder:

  • Blue-green deployment is widely used nowadays to get minimum or zero downtime. It is used by different cloud service providers like AWS (Amazon Web Services), DigitalOcean, etc.
  • Using load balancer is not the only way to implement blue-green environments. Different methods are also available like elastic IPs, DNS routing, etc.
Advantages of blue-green deployment:

1. Fast rollback
2. Reduced downtime
3. Allow testing in a live production environment without affecting 100% user base.

Disadvantages of blue-green deployment:

1. Database dependent:
Implementing blue-green deployment become complex with the database, especially if, the database schema is changed in the new version.
2. Increasingly more difficult at scale

If you've any questions about Blue Green Deployment, please let us know in the comments section below.

© The Geeky Way. Built using Pelican. Theme by Giulio Fidente on github.

Disclaimer Privacy policy