With the advent of microservices and the rise of containers to run these microservices in, there are several deployment strategies that are available to engineering teams to use to achieve continuous delivery. In this post, we will look at a few of them and discuss their pros, cons, recommendations for usage and best practices when executing these strategies.
What Are Deployment Strategies?
A deployment strategy is a way to change or upgrade an application. The aim is to make the change with no (or very minimal) downtime in a way that the end-user gets minimally impacted and the availability of the application stays high. Each application has different requirements for availability, testability, user-accpetance requirements, resources to disposal and other considerations during deployments.
Techniques to mitigate risk in your microservices deployments
There are a variety of techniques to deploy new applications to production, so choosing the right strategy is an important decision, weighing the options in terms of the impact of change on the system, and on the end-users.
In this post, we are going to talk about the following strategies:
Recreate: Version A is terminated then version B is rolled out.
Rolling (aka Ramped or Incremental): Version B is slowly rolled out and replacing version A.
Blue/Green (aka Red/Black) Deployment: Version B is released alongside version A, then the traffic is switched to version B.
Canary: Version B is released to a subset of users, then proceed to a full rollout.
A/B testing: Version B is released to a subset of users under specific condition.
Shadow (aka Mirrored): Version B receives real-world traffic alongside version A and doesn’t impact the response.
Recreate
The recreate strategy is a dummy deployment which consists of shutting down version A then deploying version B after version A is turned off. This technique implies downtime of the service that depends on both shutdown and boot duration of the application.
Pros:
• easy to setup
Cons:
• high impact on the user, expect downtime that depends on both shutdown and boot duration of the application
Rolling (aka Ramped)
The rolling updates or ramped deployment strategy consists of slowly rolling out a version of an application by replacing instances one after the other until all the instances are rolled out. It usually follows the following process: with a pool of version A behind a load balancer, one instance of version B is deployed. When the service is ready to accept traffic, the instance is added to the pool. Then, one instance of version A is removed from the pool and shut down.
Pros:
• easy to use
• version is slowly released across instances
• convenient for stateful applications that can handle ongoing rebalancing of the data
Cons:
• rollout/rollback can take time
• no control over traffic
Blue-green deployments
The blue-green deployment pattern involves operating two production environments in parallel: one for the current stable release (blue) and one to stage and perform testing on the next release (green). This strategy enables updated software versions to be released in an easily repeatable way. Devops teams can use this technique to automate new version rollouts using a CI/CD pipeline.
Pros:
• instant rollout/rollback
• good fit for front-end that load versioned assets from the same server
• dirty way to fix application dependency hell
Cons:
• expensive as it requires double the resources
• proper test of the entire platform should be done before releasing to production
Canary deployments
Named after the historical practice of sending actual birds into coal mines to see whether the air quality was safe for humans, canary deployments are a way to test actual production deployments with minimal impact or risk. The so-called canary is a candidate version of a service that catches some subset percentage of incoming requests (say, 10%) to try out new features or builds. Teams can then examine the results, and if things go smoothly, gradually increase deployment to 100% of servers or nodes. And if not? Traffic can be quickly redirected from the canary deployments while the offending code is reviewed and debugged
Pros:
• version released for a subset of users
• convenient for error rate and performance monitoring
• fast rollback
Cons:
• slow rollout
• sticky sessions might be required
• precise traffic shifting would require additional tool
A/B testing
A/B testing is similar to canary deployments, with one important difference. While canary deployments tend to focus on identifying bugs and performance bottlenecks, A/B testing focuses on gauging user acceptance of new application features. For example, developers might want to know if new features are popular with users, if they’re easy to discover, or if the UI functions properly.
This pattern uses software routing to activate and test specific features with different traffic segments, exposing new features to a specified percentage of traffic, or to limited groups. The A and B routing segments might send traffic to different builds of the software, or the service instances might even be using the same software build but with different configuration attributes (as specified in the orchestrator or elsewhere).
Pros:
• several versions run in parallel
• full control over the traffic distribution
• great tool that can be used for business purpose to improve conversion
Cons:
• requires intelligent load balancer
• hard to troubleshoot errors for a given session, distributed tracing becomes mandatory
Shadow
A shadow deployment consists of releasing version B alongside version A, fork version A’s incoming requests and send them to version B as well without impacting production traffic. This is particularly useful to test production load on a new feature. A rollout of the application is triggered when stability and performance meet the requirements.
This technique is fairly complex to setup and needs special requirements, especially with egress traffic. For example, given a shopping cart platform, if you want to shadow test the payment service you can end-up having customers paying twice for their order. In this case, you can solve it by creating a mocking service that replicates the response from the provider.
Pros:
• performance testing of the application with production traffic
• no impact on the user
• no rollout until the stability and performance of the application meet the requirements
Cons:
• complex to setup
• expensive as it requires double the resources
• not a true user test and can be misleading
• requires mocking/stubbing service for certain cases
Recommendations for usage
recreate is a good fit if downtime is not a problem
recreate and ramped doesn’t require any extra step
ramped and blue/green deployment are usually a good fit and easy to use
blue/green is a good fit for front-end that load versioned assets from the same server
blue/green and shadow can be expensive
canary and a/b testing should be used if little confidence on the quality of the release
canary, a/b testing and shadow might require additional cluster component
Parameters to choose the right deployment strategies
Best practices
In order to keep deployment and testing risks to a minimum, application teams can follow several best practices:
Backward compatibility. When you run multiple application versions at the same time, ensure that the database is compatible with all active versions.
Continuous integration/continuous deployment (CI/CD). CI ensures that code checked into the feature branch merges with its main branch only after it successfully passes dependency checks, unit and integration tests, and the build process. With CD, the CI-built code artifact is packaged and ready to be deployed in one or more environments.
Automation. If you continuously deliver application updates to the users, it is recommended that you build an automated process that reliably builds, tests, and deploys the software.
Operating environments and configuration management. Tools like Vagrant and Packer can help you maintain consistent local development, staging, and production environments.
Rollback strategy. Create a rollback strategy to follow in the case that something goes wrong.
Post-deployment monitoring. An application performance management tool can help your team monitor critical performance metrics.
Conclusion
Finally, although this blog focused on each of these strategies by themselves, there is nothing wrong with combining them to have the best possible hybrid solution that best fits your application, as well as your organization and processes you have in place.
References:
https://www.urolime.com/blogs/microservices-deployment-strategies/
https://parkardigital.com/right-strategies-for-microservices-deployment/
https://cloud.google.com/solutions/application-deployment-and-testing-strategies
