With Continuous Integration and Continuous Delivery being a best practice nowadays, you will encounter certain choices you will have to make when implementing it. One of those choices is deployment! Deployment sounds like an easy thing but can be quite complex. Usually it is dropping a war somewhere or starting a container but what if you already have a version running and you want to create zero downtime for your customers? In this article I will explain a few deployment strategies.
Strategies
When deploying you have a lot of options ranging from stopping the old application, replacing it with the new and starting it again to running the new version in shadow mode first to see if it works and then switch the loadbalancer to make a seamless switch. One being the easiest but with high impact on your customers, the last being the most complex but with hardly any impact on your customers. What is the best option? I don’t know. Every scenario has its use cases and no environment is ever the same so you should choose the one which fits your organisation and architecture the best. Lets look at some of the options first.
Recreate
Stop the old application, replace it with the new and start it again. This is the easiest strategy with the least amount of work and complexity.
Pro’s
- Very simple to setup
Con’s
- Downtime between stop and start
- Quick rollback is not possible
Rolling update
The new application is rolled out and gradually taking over requests over from the old application. Old instances are handled by the handled by the old application, but new incomming request are taken care of by the new one. At the end, the new application is taking care of all the requests.
Pro’s
- Also a simple setup. Most frameworks support this kind of a rollout.
Con’s
- You will have more versions running of the application for a short time.
- Rollback could take time.
Blue/Green
The new application is rolled out next to old one. When everything is working properly, switch the traffic over to the new one.
Pro’s
- You can check if the new application is up. When it is, you can switch.
- Rollback is relatively easy. Just switch the traffic back with a loadbalancer for example.
Con’s
- Switch using a loadbalancer of some sort is needed. Also the traffic is cut abruptly so long running transactions might get cut of.
- Costs extra resources for some time as you will be running both applications.
Canary
The new application is rolled out next to old one. You make the new application available for a subset of you customers first. This is almost the same as a Blue/Green deployment. The only difference is that you release the new application to a subset of consumers first to see how it works.
Pro’s
- Controlled rollout to your consumers
- Rollback is relatively easy.
Con’s
- More complex to set up
- Costs extra resources for some time as you will be running both applications.
Shadow
The new application is rolled out next to the old one and receives also the calls but doesn’t impact the old application and its response.
Pro’s
- You can completely test the functional and non-functional requirements of the new application with real live data
- No impact on user at all.
Con’s
- Complex to set up
- Costs extra resources for some time as you will be running both applications.
[table id=1 /]
Platform example
If you look at deployment on a platform like Oracle SOA Suite, you have a Rolling Update out-of-the-box. As you will have a composite with a new minor version, the EM will also keep the old instance but it will be inactive. This will have the big benefit that if the new version doesn’t work properly, you can quickly make the old instance active making this a quick roll back.
The Oracle Service Bus doesn’t have this luxury. As a project doesn’t have an version, maybe just by naming convention, a redeploy of the project will completely overwrite the project. If it is not working properly, you will have to redeploy the old version which will probably take a bit more time.
Down the line….
It all depends on what fits your organization, what kind of software you use and who are your customers. If there aren’t any 24×7 uptime requirements, stopping you application, redeploying and starting might not be a big issue and it is easy to do! But nowadays most organizations want to be running 24×7 with no downtime and most frameworks have things in place to manage this but it can be a broad spectrum from deploying a SOA composite on a on-prem machine to starting a new container in a Kubernetes cluster on AWS.
References: