This topic describes service release strategies that are widely used in the industry, including blue-green deployment, A/B testing, and canary release.
Blue-green deployment is a redundant deployment technique for releasing your service. Before release, a service is deployed in two versions that have the same instance types and instance quantities. The original version provides services while the new version waits in hot standby mode. When a service version is being upgraded, you can switch traffic over to the new version and place the original version in hot standby mode. This redundant deployment method ensures that resources are sufficient for the new version. If something in the new version goes wrong after it is released, you can switch traffic back to the original version. This reduces fault recovery time. After the new version is fixed and re-deployed, you can switch traffic back to this version.
Blue-green deployment uses additional instance resources to ensure availability during service release.
The following figure shows that the original version v1 of a service handles traffic while its new version v2 is deployed in hot standby mode. If you want to upgrade the service version, you can switch traffic to v2.
If v2 goes wrong, a quick rollback to v1 is performed as shown in the following figure.
- Simple to implement and easy in O&M.
- Simple and quick to perform a service upgrade.
- Requires redundant resources. Two identical production environments must be deployed.
- Affects more services if the new version goes wrong.
A/B testing routes traffic to the new version of your service based on the metadata of user requests. A/B testing is a canary release strategy that controls routing based on request content. Only requests that follow specific rules are routed to the new version. Common routing methods include HTTP headers and cookies. You can specify that the new version can be accessed only by requests whose User-Agent value is Android. Non-Android users can still access the original version. You can also configure cookie-based routing rules. Cookies contain user data that involves business semantics. For example, you can allow the new version to be accessed by regular users and the original version to be accessed by VIP users.
The following figure shows that a service has v1 as its current version and v2 as its new version to be released. In this case, Android users access v2 and non-Android users continue to connect to v1.
You can monitor the access success rate and reaction time (RT) of v1 and v2. If v2 works as expected, all requests are switched to v2. In this case, you can phase out v1 to reduce costs.
- Affects fewer services if the new version goes wrong because it provides the new version only to specific requests and users.
- Requires a complete monitoring platform to compare requests for different versions.
- Requires resource redundancy due to the inability to estimate request capacity.
- Leads to a long release cycle.
Canary release routes a small amount of traffic to the new version of your service. As such, few instances are required to deploy the new version. After you confirm that the new version works as expected, you can gradually migrate traffic from the original version to the new version as you change the traffic weights that you assign to the two versions. During the process, you can scale up the new version and scale down the original version to maximize the utilization of underlying resources.
The following figure shows that a service has v1 as its current version and v2 as its new version to be released. To ensure a smooth and lossless version upgrade, you can use canary release to gradually migrate traffic from the original version to the new version.
- Affects fewer services if the new version goes wrong because traffic is directed to the new version based on weights.
- Allows higher resource utilization because you can gradually scale up the new version and scale down the original version during a canary release.
- May affect the experience of VIP users because all traffic is indiscriminately directed to the new version.
- Leads to a long release cycle.