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 –
- Progressive Exposure Deployment
- Canary Deployment
- Blue Green Deployment
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.
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.
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.
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.
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.
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.
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.
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.
Nice blog, the articles are detailed and well explained. Like the illustrations
Having read this I thought it was very enlightening. I appreciate you finding the time and energy to put this content together. I once again find myself spending a significant amount of time both reading and leaving comments. But so what, it was still worthwhile!
Super cool article. Thank you for sharing different approaches and patterns of deployment patterns. This article has given a new perspective to think and understand DevOps as a whole.
Thanks for the feedback!
Love to see this every day !
Merely wanna remark that you have a very decent web site, I enjoy the layout it actually stands out.
I’m extremely inspired with your writing skills and also with the structure to your weblog. Is this a paid subject or did you modify it your self? Either way stay up the excellent high quality writing, it’s rare to look a nice weblog like this one today.
Remarkable issues here. I am very glad to peer your post.
Thanks a lot and I am looking forward to touch you. Will you kindly drop me a mail?
There is certainly a lot to know about this topic. I love all the points you made.
Oh my goodness! Awesome article dude! Thanks, However I am encountering troubles with your RSS. I don’t understand the reason why I cannot subscribe to it. Is there anybody else getting the same RSS problems? Anybody who knows the solution will you kindly respond? Thanks!!
I needed to thank you for this excellent read!! I certainly enjoyed every little bit of it. I have you book-marked to look at new things you post…
I’m not that much of a internet reader to be honest but your blogs really nice, keep it up! I’ll go ahead and bookmark your website to come back later on. Many thanks
Generally I don’t read post on blogs, but I wish to say that this write-up very forced me to try and do it! Your writing style has been amazed me. Thanks, very nice post.
Hello there, I found your web site via Google while looking for a related topic, your website came up, it looks great. I have bookmarked it in my google bookmarks.
Very good information. Lucky me I recently found your site by chance (stumbleupon).
I’ve bookmarked it for later!
I have learn some just right stuff here. Definitely value bookmarking for revisiting.
I wonder how so much effort you put to create any such magnificent informative web site.
There’s definately a great deal to know about this subject.
I really like all of the points you have
That is the proper blog for anyone who needs to search out out about this topic. You understand a lot its almost laborious to argue with you (not that I truly would need…HaHa). You positively put a new spin on a topic thats been written about for years. Nice stuff, simply nice!
This really answered my downside, thank you!
You made some decent points there. I did a search on the subject and found most individuals will agree with your site.