The need of different Deployment Patterns

How do we deploy a software into a production environment? What are the different ways to deploy? How do I continuously deploy and meet the various deployment requirements? What are the different deployment patterns? These are some of the questions we will try to answer in this post, Understanding Azure DevOps Deployment Patterns.
Deployment patterns, in this context, refers to various ways of deploying software continuously in Azure as part of CI/CD. In this post, I am going to talk about how we can utilize various deployment patterns to provide a safe and controlled environment for the deployments.

The most common deployment approach is what we call the ‘Big Bang’ deployment. In this approach, we take down the system, implement whatever we need to implement and then bring everything back up. This might have worked earlier, it might be the preferred approach in some cases. But in most cases, this is just not acceptable. Think about continuous deployment where we are constantly delivering. We don’t want to constantly take downtime or take down the system even though it is a planned outage. Additionally, there’s always a certain amount of risk when software goes into production. You cannot identify every scenario and every data conditions through your testing. You are bound to find problem with the code hits reality.

Deployment patterns help mitigate these risks. Keep in mind, deployment patters are not testing. In other words, the deployment pattern is a risk mitigation for the production or customer environment. I am going to talk about 3 deployment patterns with respect to DevOps practice –

  1. Progressive Exposure Deployment
  2. Canary Deployment
  3. Blue Green Deployment
Summary of Azure DevOps Deployment Patterns

Progressive Exposure Deployment

Progressive exposure deployment is a DevOps practice which relies on deployment rings. Firstly, we define the rings based on a certain criteria. Secondly, we identify and divide users or the audiences into these rings. Thirdly, we expose features to those selected set of users. After that, evaluate the impact through observation, testing, analysis of telemetry, and user feedback. Most importantly, all these steps are performed in the production region. We are actually targeting what functionality we want them to see. And it’s the targeting that’s actually a key feature of the progressive exposure pattern. Below is an illustration of how a progressive exposure deployment works in a DevOps environment.

An Illustration of Progressive Exposure Deployment

Canary Deployment

At a first glance Canary deployment looks very similar to the progressive exposure pattern. The key difference is how the new versions are targeted and the timeline utilized. The progressive exposure targets to a specific group of users for each of the rings. Canary doesn’t care. Additionally, we’re going to move through the various phases. Won’t called them rings. Phase is much quicker.

The whole idea of canary deployment is to expose the code to production, but to a very small population first. And if they identify a problem, we make sure we don’t go any further and don’t impact anyone else. So the goal is to initially expose a very small user base and then increasingly larger populations until fully deployed. This is typically percentage or weight based. We are going to deploy to lets say 1%, and if they’re okay, then 10%, then 40%, then everyone else. This is done over a comparatively rapid timeline compared to progressive exposure. We’re still going to have gates, there still might be approvals. But we’re just targeting a certain percentage, small at first to try and sniff out certain problems. Then a bigger population and we’re just going to grow the population.

An Illustration of Canary Deployment

Blue Green Deployment

The blue green deployment pattern is conceptually pretty simple. We have two environments. One of those two environments, at any given time, is the ACTIVE production environment. The other one is idle but ready. If you have a new version to deploy, then you deploy it to the INACTIVE non-production environment. If Blue is currently production, we deploy to green. On this environment, you could do any kind of testing, validation or checks. Once we are ready, we can switch the live endpoints from blue to green. As a result, green is now the active production. This means the previous live environment, blue, is now inactive. It will be used for the next software version. Or if there’s a problem, we can roll back by just switching the environments. The key point here is we have an entire duplicate environment and we can switch back and forth between these environments.

An Illustration of Blue Green Deployment

Comparing the Deployment Patterns

In order to compare the various azure DevOps deployment patterns, let me try to break it down by cost and benefit.

Big Bang Deployment

Firstly, we have the big bang approach. We have an existing environment, so just take it down, deploy the code, and bring it back up. Therefore, the benefit of this is simplicity. The trade-off here is the downtime. To be very clear, this might be the right solution. We can take a downtime, that’s absolutely fine. If this is the right solution, it’s very simple. The flip side is, it’s very hard to mitigate any risk, though. If we find some problem during the deployment or upgrade, the downtime will increase as we troubleshoot the issue.

Progressive Exposure

Secondly, when it comes to progressive exposure, the benefit that you get is control. You have a high degree of control as the package moves through the rings. You have a lot of gates and approvals in place to ensure cleaner deployment. The trade off here is the complexity. You have to do a lot of things in order for this to make it work. You also have a very long deployment time.

Canary Deployment

Thirdly, we have Canary deployment. Like progressive, I’m targeting a population, but this isn’t targeted through any kind of criteria. I am just changing the size of user that gets the deployment without having to go through the complexity of defining the exit criterion. So, I have very good control and its simpler than progressive. Downside, though, there is still some complexity to this. The release pipeline still has certain different stages, there’s certain gates and I also have approvals I may require.

Blue Green Deployment

Lastly, the Blue Green deployment. The good thing about Blue Green deployment is there is very less to no downtime. The negative is the whole second environment. Now, in the cloud, we can offset this a lot. Because it’s consumption‑based, I can spin this up as it’s needed. It’s not sitting there idle for most of the time. Now, there still is additional resource utilization. If we are doing a continuous deployment, this may be constantly being utilized multiple times a day. So that’s the trade off. I get simplicity with this. I’m trading off resource utilization.

A cost-benefit comparison of various Azure DevOps Deployment Patterns

Just to be clear, the comparison shown does not conclude if anyone is better than the other. It just tries to depict the benefits and the trade-offs. Consider this as pointer to help you decide which pattern to choose.

To Conclude…

I hope I was able to shed some light on various Azure DevOps Deployment Patterns. At some point in the future, I might write individual post about each of them. In the mean time, you can do some reading here.
Lastly, I would put out a word of caution. Do not over-engineer or over-architect these things. There are complexity costs. There are dollar costs for various types of deployment patterns. Do not try to force a deployment pattern to meet certain requirements. Keep it simple, evaluate the cost-benefit and make a choice.