Deployment Strategies

While deploying to cloud, the traditional application deployment techniques may not be sufficient. Traditional techniques like hot deployment or rolling deployment might work well, while deploying to a small cluster of machines. In traditional deployment techniques, since the application is not distributed, if an issue is discovered post deployment, it is relatively simple to perform a rollback.

Imagine a cloud environment, which has hundreds of instances of a service/application. In such an environment, if we use the traditional approach of deploying to all the machines at once, just imagine, what would happen if an issue is detected post deployment? It would be nightmarish to perform rollback on each and every machine. Also, in a Microservices Architecture, there could be lot of services interacting with each other and rolling back may not be a trivial task. Obviously, we would need a modern cloud enabled deployment strategy.

Also, with continuous integration and deployment techniques, we are moving towards a shorter development to production cycle and hence increased frequency of releases. This, in turn, makes it more important to have an effective deployment technique which provides guard against any post deployment issues.

There are two popular Deployment Strategies:

1. Blue Green Deployment
2. Canary Deployment

1. Blue Green Deployment:

In this deployment technique, we will need to maintain two copies of the infrastructure during deployment, which could be named ‘Blue’ and ‘Green’.

Blue:

One part of the infrastructure (known as Blue) hosts the currently running version of the application.

Green:

We need to have a separate set of infrastructure (known as Green), which is identical to the other.

Deployment Process:

The new version of the application will be deployed on Green. At this point, we need to route the incoming requests to Green infrastructure. We need to retain this setup for a while and monitor and test the application. If we don’t find any issues, we can discard the Blue environment. If something is wrong, then we need to switch the requests back to Blue. With cloud enabled infrastructure and automated deployment, we can quickly setup/tear down new environments. Post successful deployment, the Blue environment could also be used for Staging/UAT testing.

Challenges:

1. While switching from Blue to Green or vice versa (during rollback), if there is a transaction which is in progress, we need to gracefully handle those transactions and allow them to complete.
2. Database changes: If there are significant changes to database in the new release, it may not be easy to switch requests between Blue and Green. One of the solutions to this is to use DB refactoring. DB Refactoring is a process of making changes to a database so that it supports both older and newer versions of the software.
3. Requires two copies of infrastructure during deployment time and could be an overhead.

2. Canary Deployment:

Canary got its name from a bird which is used in coal mines to check for the presence of toxic gases.

In this technique, the new version of software is deployed to a small subset of servers (infrastructure). A small subset of user requests is routed to this subset of servers. Typically, users could be selected by geographical location, or based on division/company to which the user belongs to. The application is then tested for sanity. If everything is fine, then slowly, the new version of software is deployed to larger set of servers is incrementally (and routing larger set of user requests to it) until all the servers are covered.

Challenges:

1. As in Blue/Green, managing Database changes is a challenge, especially, if the database changes are disruptive (involving major schema changes).