This is the 10th day of my participation in the August Text Challenge.More challenges in August

The biggest challenge in upgrading applications is switching between the old business and the new business, moving software from the final stages of testing to production, while maintaining uninterrupted system service.

Over a long period of time, service upgrade gradually formed several publishing strategies: blue-green publishing, grayscale publishing and rolling publishing, in order to avoid traffic loss or service unavailability problems caused by publishing as much as possible.

Blue green deployment

Blue-green deployment refers to running two versions of an application at the same time. As shown in the figure above, blue-green deployment does not stop the old version, but directly deploys a new version and switches traffic to the new version when the new version is running. However, blue-green deployment requires you to run two applications simultaneously during the upgrade process, requiring twice as much hardware as you would normally need. For example, if you need 10 servers to support your business, you would need to purchase 20 servers for blue-green deployment.

The characteristics of

  • If something goes wrong, the impact is larger;
  • Simple release strategy;
  • No user perception, smooth transition;
  • Fast upgrade or rollback speed.

disadvantages

  • Prepare servers twice as many as normal service resources to prevent a single group from bearing service emergencies during the upgrade.
  • A certain amount of resource cost is wasted in a short time;
  • Infrastructure is not changed to increase upgrade stability.

Blue-green releases were expensive in the early days of physical servers, but with the spread of cloud computing, costs have dropped dramatically.

scrolling

Rolling publishing solves the problem of doubling the hardware requirements for blue-green deployments.Alleged rolling upgrade, it is in the process of upgrading, not all of a sudden start all the new version, is to launch a new version first, then stop an old version, and then start a new version, to stop an old version, until the upgrade is complete, in that case, if the daily need 10 server, the upgrade process is just need 11 sets.

However, there is a problem with rolling upgrade. After rolling upgrade, traffic will flow directly to the new version that has been started, but at this time, the new version may not be available, for example, further testing is required to confirm. During a rolling upgrade, the entire system is in a very unstable state, and if a problem is found, it is difficult to determine whether the problem is caused by the new version or the old version.

To solve this problem, we need to implement flow control capabilities for rolling upgrades.

The characteristics of

  • No user perception, smooth transition;
  • Save resources.

disadvantages

  • Slow deployment time, depending on the update time of each phase;
  • Release strategy is complex;
  • Unable to determine the OK environment, not easy to rollback.

Gray released

Grayscale publishing is also called canary publishing. The origin is that mine workers found that canaries were sensitive to gas, and miners would put a canary into the well before they went down. If the canary stopped calling, it would mean high gas concentration.At the beginning of gray release, first start a new version of the application, but not directly cut over the flow, but the tester on the new version of the online test, the new version of the application, is our canary. If there are no problems, A small amount of user traffic can be imported to the new version, and then the new version can be observed to collect various runtime data. If various data are compared between the old version and the new version, it is called A/B test.

As the new version is confirmed to be working well, more traffic can be progressively imported to the new version, and the number of server replicas running on the old and new versions can be constantly adjusted to make the new version more and more capable of handling the traffic. Until 100% of the traffic is switched to the new version, and finally the rest of the old version service is shut down to complete the grayscale release.

If a problem with the new version is found during grayscale release (grayscale phase), the traffic should be switched back to the old version immediately. In this way, the negative impact will be minimized.

The characteristics of

  • To ensure the stability of the whole system, problems can be found and adjusted at the time of the initial gray scale, and the scope of influence can be controlled;
  • New features progressively assess performance, stability and health, and if problems occur, the impact is minimal relative to the user experience;
  • Smooth transition without user perception.

disadvantages

  • High automation requirements

summary

To sum up, all the three methods can achieve smooth upgrade. During the upgrade, the service continuity is maintained and the upgrade is unaware of the outside world. Which deployment method is best for production? It depends on which approach best suits your business and technical needs. If your operation and maintenance automation capacity reserve is not enough, the simpler the better, we suggest blue-green release, if the business is very dependent on users, we suggest grayscale release. For K8S platform, rolling update is a ready-made solution. It is recommended to use it directly first.

  • Blue-green release: Two sets of environments are upgraded alternately, and the old version is retained for a certain period of time to facilitate rolling back.
  • Grayscale release: Upgrade the old version according to the proportion. For example, 80% users access the old version and 20% users access the new version.
  • Rolling publishing: Stop old version instances by batch and start new version instances.