Deployment Architecture and DevOps

The biggest change we can expect today and, in the future, is the pace of the deployment. Waterfall model, in which release cycles used to last months and years, is now rare. And Product teams deploying releases to production earlier (and more often).                        

Today with Service Oriented Architecture and Microservices, code base is a collection of loosely coupled services. Hence the developers write and deploy changes in different parts of the code base simultaneously and frequently.

The business advantages of shorter deployment cycles are clear:

•      Time-to-market is reduced

•      Customers receive product value in less time

•      Customer feedback also flows faster back into the product team, enabling the team to track features and fix issues quickly

•      Overall developer morale is rising

This move, however, also creates new challenges for the DevOps team. With more frequent releases, there is a risk that the code deployed will adversely affect the functionality of the website or the customer experience. That's why it's important to develop code delivery strategies that minimize risk to both the product and customers.

To meet these challenges, application and devops team must devise and adopt a deployment strategy suitable for their use case. I will talk about 2 such deployment strategies here.

Blue Green Deployment

In Blue Green deployment two identical servers or production environments are maintained, named Green and Blue.

At one time only one environment is live. For this example, Blue is the one which is currently running with the latest production code, receiving all user traffic. Green is currently idle but has the exact same system configurations.

Now the development team will deploy new version of the application to Green. Internally the testing will begin, and upon successful result, entire application traffic will be routed to Green from Blue. Now Green is the new production.

Below are the benefits that I find useful:

•      Power of Rollback (reduced risks) – If there’s an issue after Green becomes live, we can quickly switch back to Blue and work on fixing the problem. Hence the production is still live and up with the older version.

•      No Downtime – As one of the two parallel environments are up always there’s no question of downtime

•      Less bugs – As team will test new feature in a production environment there’s extremely less chances of bugs

Canary Release

Canary is not very different than Blue Green Deployment, except it is risk-averse. Let’s talk about the origin of the name canary deployment. In old British mining practice canary birds were first sent to mines to detect carbon monoxide and other toxic gases, to make sure if its safe for humans.

So how it is comparable with our context? Well when we want to send a new version of an application to production, we can use a canary to make sure the new changes can survive for a broader public. With Canary deployment we can deploy a new application code to a smaller part of production infrastructure and make only a small percentage of real users routed to it. This minimizes any impact. With no bugs or errors reported, the new version can be gradually rolled out to the rest of the live users. 

benefits include:

•      With any error reported we can safely roll back to older version

•      No downtime in case of any issue

•      Multiple layers of testing, including internal testing and Capacity testing of new version in a production environment

•      Can be monitored about how the new version impacts

•      Based on business need it can be released in a specific geographic region

•      Based on business need a new feature can be released to specific users and groups