This content originally appeared on Level Up Coding - Medium and was authored by Andrii Drozdov
When it comes to deployment, one major question you may have is what deployment pattern (strategy or type) I should pick.
Some of the strategies are quick to implement but have a lot of downsides, while other are longer in implementation and require a lot of effort to sustain it.
Today we will talk about:
- Recreate
- Ramped
- Blue/Green
- Canary
- A/B testing
- Shadow
In any case, let us look closer at each of the existing strategies.
Recreate
Or it may be named Default or Standard.
The most used and popular strategy. Details may vary depending on the infrastructure that you use in your project but a core idea is pretty simple.
How it works — you deploy a new version and replace the old one. Totally. All the traffic is heading to the newly deployed version.
The more academic definition will be:
Rolling out a new version of software totally replacing all instances of the previous one simultaneously.
Pros
- fast implementation
- cheap implementation & support
- no headache with load-balancer
- no possible dev-fault
Cons
- no scalability
- no control over traffic
- impossible to support multiple APIs
- depending on infrastructure, there may be downtimes
- depending on implementation, it may take time to rollback
When to use it:
- in tide budget or limit in developers
- when you need to rollout code-base fast
- when you need straight-forward solutions
- when the overall expertise of the company is low
Ramped
Or it can be named Staged.
Ramped rollout is a way of deployment when old instances are being replaced with new ones slowly, one by one. The main difference between Recreate and Ramped is that Ramped strategy replaces instances one by one instead of replacing all instances at once.
This one is more complex in implementation than Recreate and it’s harder to maintain.
Pros
- fairly easy to implement
- easy to monitor the deployment process and rollback if something will go wrong in the middle of a deployment
- usually considered a zero downtime strategy
Cons
- slow deployment and slow rollback
- requires much more effort from developers in comparison with Recreate
- requires a lot of CI/CD minutes usage
- it is required to put effort into the correct setup server
When to use it:
- when the product is evolved from a small to medium size project
- when you’re moving from monolith architecture to micro-service
- when you want more control over the deployment process
Blue / Green
Or in web red / black strategy.
The explanation for blue / green deployment strategy will be simple:
It’s a way of deployment when you have both versions running in parallel and only specific users have access to the newly deployed instance, usually those users are testers.
When it was properly tested you switch from the old version to the new version for all other users and disable the old software.
Pros
- avoid any inconsistency between different environments for testing
- proper quality verification
- there’s a lower chance that users will be affected by bugs
- instant rollout
- considered as zero downtime solution
Cons
- expensive from a financial point of view solution (you need to run two servers simultaneously)
- clearing test data after testing may be tricky
When to use it:
- when the project passes a small stage
- when the project has enough engineers to provide QA & delivery
- when the project has enough time to make this type of deployment
- when you want to increase product quality
Canary
Canary deployment strategy can be defined as a strategy that makes software available only for a small percentage of users after deployment. So for example you put 10% of your traffic from the old version to the new one.
One of the best strategies for focusing on product quality and stability.
Pros
- production quality verifications
- software stability and monitoring
- considered as zero downtime solution
- fast rollback
Cons
- the expensive solution, you need to maintain two instances at the same time
- slow rollout
- time-consuming deployment cycle
When to use this solution:
- when you prefer quality and stability over speed
- when the project is medium to large+ size
A / B Testing
A / B Testing is more referred to as a way of doing testing, more than deployment type, but it is still worth to be mentioned. In a nutshell, it’s really close to Canary deployment strategy, except for one small difference, with A / B testing we are targeting specific user groups to use the new version, like, gender, device OS, occupation, whatever.
Pros and cons are pretty much the same as in Canary strategy.
When to use this:
- in cases, when features are sensitive to target users
Shadow
The most interesting and efficient way of handling deployment.
Can be used in parallel with other approaches.
Basically, after deploying your product function as it was before, you still have your old version as the main version, but in parallel, you proxy your requests to the new version.
Pros
- you can monitor everything that is happening with your product, load, bugs, real behaviour
- fast rollout
- fast rollback
- considered as zero downtime solution
Cons
- the expensive solution, you need to have two instances at the same time and you need developers who will validate everything
- time-consuming deployment cycle
- risks to corrupt data
- hard to implement
When to use this solution:
- when you have a medium+ project size
- when you have a lot of changes each delivery cycle
- when you can afford your self infrastructural problems that create this solution
- when you prefer quality over speed
Conclusion
Well, guys, that’s it for today.
What is better to use — it’s up to you.
Some of these strategies are widely used, and some of them can be found rarely. There is no silver bullet.
Most of the factors, that will help you to make a decision are:
- budgets
- project complicity
- company structure
- available resources (cross-departments)
- infrastructure
As always, you friendly neighbourhood developer.
Follow me for more! Cheers!
Deployment Strategies was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Andrii Drozdov
Andrii Drozdov | Sciencx (2023-01-09T03:25:55+00:00) Deployment Strategies. Retrieved from https://www.scien.cx/2023/01/09/deployment-strategies/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.