- instructions
- Blue green deployment
- Published by Canary
- A/B testing
- reference
instructions
Blue-green deployment, A/B testing, canary publishing, as well as grayscale publishing, traffic sharding, etc., are often lumped together, affecting communication efficiency. The root cause is that these terms appear so often that people are familiar enough to talk about them, but there is no consensus on their understanding of them.
The following definitions are compiled from Blue-green Deployments, A/B Testing, and Canary Releases.
Blue green deployment
The purpose of blue-green deployment is to reduce outage times at release time and to be able to withdraw releases quickly.
It’s basically a technique for releasing your application in a predictable manner with an goal of reducing any downtime associated with a release. It’s a quick way to prime your app before releasing, and also quickly roll back if you find issues.
In the blue-green deployment, there are two systems: one that is providing services and is marked green; The other is a system ready for release, marked “blue”. Both systems are fully functional and running systems, but the system version and external services are different.
Initially, there was no system, no blue or green.
Then, the first system is developed and goes online directly. There is only one system in this process, and there is no blue or green.
Later, a new version is developed to replace the old version online, and a whole new system is built using the new version code in addition to the online system. At this time, two systems are running. The old system is green and the newly deployed system is blue.
The blue system does not provide external services. What is it used for?
Used for pre-release testing, any problems found during the test can be directly modified on the blue system, without interfering with the system users are using. (Note that only when the two systems are not coupled can there be 100% guarantee of no interference)
After repeated testing, modification and verification of the blue system, users will be directly switched to the blue system after meeting the online standard:
For a period of time after the switch, the blue and green systems still coexist, but the user accesses the blue system. During this period, observe the working status of the blue system (new system), and switch back to the green system if there is a problem.
When the blue system that provides services to the outside is believed to work properly and the green system that does not provide services to the outside is no longer needed, the blue system officially becomes the new green system that provides services to the outside. The original green system can be destroyed, freeing up resources for the deployment of the next blue system.
Blue-green deployment is just one of the go-online strategies, and it’s not a one-size-fits-all solution. Blue-green deployments can be implemented easily and quickly assuming that the target system is very cohesive. If the target system is quite complex, you need to think carefully about how to switch, whether the data between the two systems is needed, and how to synchronize.
One image in particular from BlueGreenDeployment:
Published by Canary
Canary release (Canary) is also a release strategy, and domestic often said grayscale release is the same kind of strategy.
Blue-green deployment is to prepare two systems and switch between them. Canary strategy is to have only one system and replace it gradually.
For example, the target system is a set of stateless Web servers, but there are a lot of them, let’s say 10,000.
At this point, blue-green deployment will not work, because you cannot request 10,000 servers dedicated to deploying a blue system (in the definition of blue-green deployment, the blue system should be able to handle all access).
One way to think about it is:
Prepare only a few servers on which to deploy and test the new version of the system. After the test passed, I was afraid to update all the servers immediately for fear of accidents. Start by updating 10 of the 10,000 servers online to the latest systems, and then observe and verify. After verifying that there are no exceptions, update all remaining servers.
This method is canary publishing.
More control can be exercised, such as setting a lower weight for the first 10 updated servers, controlling the number of requests sent to those 10 servers, and then gradually increasing the weight and number of requests.
This control is called “traffic sharding” and can be used for both Canary releases and later A/B testing.
Blue-green deployment and Canary publishing are two publishing strategies, and neither is a panacea. Sometimes you can use both, sometimes you can only use one or the other.
In the example above, you can use canary but not blue and green, so when can you use blue and green and not canary? When the entire system has only one server.
A/B testing
The first thing to be clear about is that A/B testing and blue-green deployment and canaries are two very different things.
Blue-green deployment and Canary are release strategies that aim to ensure the stability of a new system, focusing on bugs and hidden dangers of the new system.
A/B test is an effect test in which multiple versions of services are available at the same time. These services have been tested enough to meet the online standards, but there is no difference between new and old services (they may be deployed in blue-green mode when they are online).
A/B testing focuses on the actual effects of different versions of the service, such as conversion rates, order levels, etc.
In A/B testing, multiple versions of services are running online at the same time. These services usually have some differences in experience, such as page style, color, and operation flow. Analyze the actual effect of each version and select the version with the best effect.
In A/B testing, you need to be able to control the distribution of traffic, for example, 10 percent for version A, 10 percent for version B, and 80 percent for version C.
reference
- Blue-green Deployments, A/B Testing, and Canary Releases
- BlueGreenDeployment
This article was originally published on www.lijiaocn.com