This is the 31st day of my participation in the August More Text Challenge

Today I will introduce some common service deployment and upgrade strategies. Without further ado, I will introduce them separately.

1, downtime deployment

introduce

Downtime deployment is the simplest and most crude way to simply shut down the existing version of the service and deploy the new version. At some point, we have to deploy or upgrade multiple services in this way. For example, the new version of the service uses a data table design that is completely incompatible with the old version. At this point, we had two changes to production, one to the database and the other to the service, and the old and new versions were incompatible, so we had to use an outage deployment. The advantage of this approach is that the new and old versions are not online at the same time during deployment, and all states are identical. Downtime deployment is mainly due to new release consistency issues.

disadvantages

The worst problem with this approach is that it will be down, which will have a great impact on users. As a general rule, this type of deployment requires a pre-announcement and a low-access period.

2. Blue-green deployment

introduce

The biggest difference between a blue-green deployment and an outage deployment is that it deploys the same number of new services on the production line and then switches traffic to the new service when the new service is tested and OK. The advantage of blue-green deployment over downtime is that it requires no downtime. We can see this kind of deployment, which is what we call a pre-launch environment. In my former financial company, there are two sets of the same cluster on the production line. One set is Prod, which is the real service, and the other set is Stage, which is the pre-release environment, releases Stage, and then cuts the flow to Stage, so Stage becomes Prod. The previous Prod became Stage. It’s kind of like page-changing.

advantages

The advantage of this approach is that there is no downtime, real-time releases and updates, and the problem of having new and old versions online at the same time is avoided.

disadvantages

The problem with this kind of deployment is that it’s a bit wasteful, because it takes twice as much resources (although this is only in the era of physical machines, it’s fine in the era of cloud computing, because the virtual machine can be released once it’s deployed). In addition, if we have state in our service, such as some cache or other, both the down deployment and the blue-green deployment will be problematic.

3. Rolling deployment

introduce

A rolling deployment strategy is the slow release of a new version of an application by replacing all instances of the application one by one. The usual process is as follows: After load scheduling, an application instance pool of version A is created. When an instance of version B is successfully deployed and can respond to requests, the instance is added to the pool. Then, an instance of version A is removed from the pool and taken offline. This deployment mode directly upgrades existing services, which, while easy to operate, is also friendlier to stateful services in the slow update process, where state can be slowly rebuilt. However, this deployment is fraught with problems.

disadvantages

During the release process, the old and new versions may be online at the same time, and requests from the same user may switch between the old and new versions, causing problems. Our new version went live without being proven on the production line. During the whole process, the production environment is in an intermediate state of new and old replacement, and it is a bit troublesome to roll back if there is a problem. If we need to do some other operation and maintenance work during the upgrade process, we also need to determine which nodes are the old version and which nodes are the new version. It’s too painful. Because the old and new versions of the code are online at the same time, it depends on a service that needs to handle requests from both versions at the same time, which can cause compatibility problems. Also, we can’t switch traffic between old and new versions.

4. Canary Deployment

introduce

Gray scale deployment is also called canary deployment. It gets its name from the canary in the mine — in the 17th century, English miners discovered that canaries were sensitive to gas. Canaries stop singing when there is even the tiniest trace of gas in the air. And when the gas levels rise above a certain limit, the canaries die of the poison, though dull humans do not notice. With relatively rudimentary mining equipment, workers took a canary with them every time they went down to the mine as a “gas indicator” to evacuate in case of danger. Grayscale deployment refers to gradually switching the production environment traffic from the old version to the new version. Traffic is usually distributed proportionally. For example, 90% of requests go to the old version and 10% go to the new version. Then, if no problems are found, the traffic on the new version is gradually increased and the traffic on the old version is reduced. In addition to traffic cutting, for multi-tenant platforms, such as cloud computing platforms, grayscale deployment can also deploy some new versions to some users first. If there is no problem, the deployment can be expanded to all users. The general strategy is to start with internal users, then general users, and finally big customers. This technique is mostly used when there is a lack of adequate testing, or a lack of reliable testing, or a lack of confidence in the stability of the new version. Switch some users to the new version and see if there is any problem. If there are no problems, continue to expand the upgrade until the upgrade is complete.

5. AB test

AB testing is completely different from blue-green deployment or Canary grayscale deployment. The AB test is to launch two versions at the same time and then do a relative comparison. Is a way to test the performance of an application’s functionality, such as usability, popularity, visibility, etc. Blue-green deployment is for non-stop, grayscale deployment is not confident in the quality of the new version. The AB test is not confident in the functionality of the new version. Notice, one is quality, one is functionality.

For example, the website UI is greatly revised, the recommendation algorithm is updated, and the process is changed. We don’t know whether the new version will be favored by users or get better user experience. We need to collect certain user data to know.

So what we need to do is launch two versions on the production line, take some users and use them as guinea pigs, and then make scientific observations to come up with relevant conclusions. AB test aims to obtain representative experimental conclusions through scientific experimental design, sample representativeness, flow segmentation and small flow testing, and make sure that the conclusions are credible when extended to all flows. We can see the AB test, which includes the grayscale publishing function. That is to say, if our observation is just to observe there is no bug, that is grayscale release. Of course, if we are a little more complicated, to observe some of the user’s data indicators, it is completely possible to make automatic, if the new version of the data is good, automatically cut a little traffic over, if not, a new group of users (sample) try again. For grayscale distribution or AB testing, you can use the following techniques to select users.

  • Browser cookie.

  • Query parameters.

  • Geographical location.

  • Technical support, such as browser version, screen size, operating system, etc.

  • Client language.

summary

There are many ways to deploy an application, and the actual approach depends on requirements and budget. When publishing to development or simulation environments, downtime or rolling deployment is a good choice because it is clean and fast. Rolling deployment or blue-green deployment is usually a good choice when releasing to production, but main process testing for the new platform is a must. Blue-green deployments are also good, but require additional resources. If the application is poorly tested or if you lack confidence in the functionality and stability of the software, you can use Canary deployment or AB test release. If the business needs to test specific users based on geographic location, language, operating system, or browser characteristics, the AB testing technology can be used.

– END –

Author: The road to architecture Improvement, ten years of research and development road, Dachang architect, CSDN blog expert, focus on architecture technology precipitation learning and sharing, career and cognitive upgrade, adhere to share practical articles, looking forward to growing with you. Attention and private message I reply “01”, send you a programmer growth advanced gift package, welcome to hook up.

Thanks for reading!