Microservice deployment: comparison and summary of deployment schemes such as blue-green deployment, rolling deployment, and grayscale release

http://www.itmuch.com/work/microservice-deploy/
In the process of project iteration, it is inevitable to "go online". Going online corresponds to deployment, or redeployment; deployment corresponds to modification; modification means risk.

There are many technologies for deployment, some are simple, some are complex; some require downtime, and some can be deployed without downtime. In this article, the author briefly discusses several popular deployment schemes, or strategies. If there is any inadequacy, please point out, and if there is any error, please correct me ^_^.

Blue/Green Deployment Blue-

green deployment requires no downtime and is less risky.

(1) Deploy the application of version 1 (the initial state), and

all external request traffic goes to this version.

(2) Deploying an application of

version 2 The code of version 2 is different from that of version 1 (new features, bug fixes, etc.).

(3) Switch traffic from version 1 to version 2.

(4) If the test of version 2 is normal, delete the resources (such as instances) in use by version 1, and officially use version 2 from now on.

It is not difficult to find from the process that our application is always online during the deployment process. In addition, during the launch of the new version, nothing of the old version has been modified, and the status of the old version will not be affected during deployment. This risk is small, and in theory, we can roll back to the old version at any time, as long as the old version of the resource is not deleted.

rolling update (rolling release)

rolling release, generally take out one or more servers to stop the service, perform the update, and put it back into use. Repeat this cycle until all instances in the cluster are updated to the new version.

This deployment method is more resource-efficient than blue-green deployment - it does not need to run two clusters and twice the number of instances. We can deploy partially, for example, take out only 20% of the cluster each time to upgrade.

This method also has many disadvantages, such as:

(1) There is no environment in which OK is determined. With blue-green deployments, we can clearly know that the old version is OK, while with rolling releases, we can't be sure.

(2) Modified the existing environment.

(3) If you need to roll back, it is difficult. For example, in a release, we need to update 100 instances, 10 instances at a time, and each deployment takes 5 minutes. When rolling out to the 80th instance, a problem was found and it needed to be rolled back. At this point, bad-tempered programmers are likely to want to flip the table, because rolling back is a painful and lengthy process.

(4) Sometimes, we may also dynamically scale the system. If the system automatically expands/shrinks during deployment, we also need to determine which node uses which code. Despite some automated operations tools, it's still scary.

It's not that rolling releases are bad, there are scenarios where rolling releases are well suited.

Grayscale release/canary deployment

First post on Baidu Encyclopedia:

Grayscale release refers to a release method that can smoothly transition between black and white. AB test is a grayscale release method, allowing some users to continue to use A, and some users to start using B. If users have no objection to B, then gradually expand the scope and migrate all users to B. Grayscale release can ensure the stability of the overall system, and problems can be found and adjusted at the initial grayscale to ensure their influence.

Many people confuse the grayscale release with the blue-green deployment. The author believes that the most similar to the grayscale release should be the canary deployment.

A "canary deployment" is a type of incremental release that is performed by deploying a new version at the same time as the original production version of the software is available. Running multiple versions of the same software product at the same time requires the software to be specially designed for configuration and perfectly automated deployment.

Let's take a look at the steps for a canary deployment:

(1) Prepare artifacts for each stage of deployment, including: build artifacts, test scripts, configuration files, and deployment manifest files.

(2) Remove the "canary" server from the load balancing list.

(3) Upgrade the "canary" application (drain the original traffic and deploy it).

(4) Automated testing of the application.

(5) Add the "canary" server back to the load balancing list (connectivity and health checks).

(6) If the "Canary" online use test is successful, upgrade the remaining other servers. (Otherwise, it will be rolled back.) In

grayscale releases, routing weights are often set according to users. For example, 90% of users maintain the old version, and 10% of users try the new version. Coexistence of different versions of the application is often used in conjunction with A/B testing to test multiple options. A typical example of grayscale release is the "new version" of Alibaba Cloud. Click "Enter new version", and we become a canary.

Fun Fact: Canary deployment (similar to canary testing), the origin of the "canary": In the 17th century, British mine workers discovered that canaries were very sensitive to the gas. Even if there is a very small amount of gas in the air, the canary will stop singing; when the gas content exceeds a certain limit, although the dull human will not notice, the canary has already died of poisoning. At that time, when the mining equipment was relatively crude, the workers would bring a canary as a "gas detection indicator" every time they went down the mine, so that they could evacuate in a dangerous situation.

Summary

(1) Blue-green deployment: Do not stop the old version, create a new version, and delete the old version after the test finds that the new version is OK.

(2) Rolling release: Stop the old version instance in batches and start the new version instance.

(3) Grayscale release/canary deployment: Do not stop the old version, create a new version, and often set the routing weight according to the user. For example, 90% of users maintain the old version, and 10% of users try the new version. Coexistence of different versions of the application is often used in conjunction with A/B testing to test multiple options.