A/B deployment – DevopsCurry

Blue-green Deployment Explained: The Secret to ZERO Downtime

Wed, 25 Sep 2024 03:52:14 +0000

This article talks about what is blue-green deployment and how it helps to reduce downtime to improve end-user experience.

Introduction to Blue-green Deployment

Frequent and quality deployments are a core principle of DevOps. However, whenever you need to deploy a new version, you must stop the current one first. This leads to significant downtime for the end user and can affect customer experience. Moreover, if any bug or error is found after release, it will require additional downtime to withdraw the updated version and switch back to the old one. This process is how newer versions of the application were deployed conventionally.

A modern approach that solves the problem of downtime and time-consuming rollback procedures is blue-green deployment. Although a bit complicated, blue-green deployment requires ‘zero’ downtime and makes rollbacks easier, thus ensuring seamless user experiences.

But how does it work?

How does Blue-green Deployment Work

Blue-green deployment involves 2 production environments:

‘Blue’ environment is the old/active environment.
‘Green’ environment is the newest environment that needs to be deployed.

As per the traditional method, the blue environment should be stopped first and the green environment should be deployed in its place. However, in blue-green deployment, the green environment is deployed alongside the blue one so that both of them run simultaneously. Then, the user traffic is gradually shifted from the blue environment to the green one. Once all of the traffic has been successfully shifted to the green environment, the blue environment is finally withdrawn. Therefore, there occurs no downtime for any user as both the old and the new versions stay active.

The following illustration depicts how traffic is shifted from the blue environment to the green environment…

Image credits: What is Blue/Green Deployment?

But I also mentioned that it makes rolling back easier in case of bugs, right? How does that work?

So, when the traffic is being shifted from the blue environment to the green one, the latter is closely monitored for any signs of errors or bugs. If any of them occurs, whatever traffic that lies in the green environment is shifted back to the blue environment. The green one is then rolled back for redevelopment and retesting. In this way, blue-green deployment makes rolling back easier in case of bugs that might have bypassed the testing phase but are evident only when actual users interact with it.

All the steps involved in blue-green deployment can be summarized as follows…

Image credits: Blue-green deployment

Benefits

The following are the main advantages of blue-green deployment:

Rapid releases: Earlier, development teams had to wait for off-peak times like midnight to deploy new features so that the downtime affects minimum user traffic. But with blue-green deployment, new versions can released spontaneously without any risk of downtime. That said, it helps to achieve continuous delivery (CD).
Easier rollbacks: As discussed before, blue-green deployment makes rolling back updates simpler without requiring any additional downtime. It makes the deployment process even more risk-free.
A/B testing: A major advantage of blue-green deployment is that it allows for A/B testing. For this, a new code is loaded into the blue environment instead of the green one. A part of the traffic (usually 50%) is sent to the green environment while the other half remains in the ‘newer’ blue environment. Then both of these environments are monitored to decide which one works best and appeals to the audience more.
Improved customer experience: Overall, blue-green deployment helps to improve user experience by limiting downtime and providing 24/7 availability.

Challenges & Limitations

Although blue-green deployment sounds ideal, it comes with a few challenges and limitations:

Demanding: Using the blue-green deployment approach can be expensive as it requires you to keep two nearly identical environments active simultaneously. Also, it requires smooth and effortless coordination between the teams and its members.
Set up time: Initially, setting up blue-green deployment can be a time-intensive process and may require many tries before it is perfected.
Complex traffic routing: Moving traffic from one environment to the other (traffic routing) smoothly can be a complex task and may sometimes cause latency issues. Tools like load balancers may have to be used.
Not applicable to all applications: Blue-green deployment is difficult to apply in the case of stateful applications. This is because if a user is active in the blue environment, his/her user session may get interrupted or lost after making the switch to the green environment.

Conclusion

Blue-green deployment is a modern solution that effectively addresses the downtime problem, ensuring a smoother and more reliable user experience. By running two environments in parallel and switching traffic seamlessly between them, it eliminates the need for downtime during updates. It comes with an added advantage of easier rollbacks which makes it suitable for teams looking to improve their deployment efficiency. While it does have its limitations, such as infrastructure costs and setup complexity, the overall benefits make it a powerful strategy for delivering continuous and uninterrupted services.

The post Blue-green Deployment Explained: The Secret to ZERO Downtime appeared first on DevopsCurry.

Devops 2024: Best Popular Deployment strategies

Sat, 04 May 2024 16:29:54 +0000

Different Devops Deployment strategies to consider in 2021

One of the phases of Software Development Lifecycle (SDLC) is Deployment. Like any other stage this holds a very important place in the lifecycle. In simple terms project deployment is a process of making the application ready to deliver to the end users. It involves multiple steps, systematic processes before the application is delivered to the customers. The process of deployment involves software release, installation, rigorous testing, and most importantly performance monitoring.

The deployment strategy is a method to alter or enhance an application. The primary concern in deployment is to make the change in such a way that the end-user does not feel any discomfort while using the application. To help overcome any issue while migration, there are several techniques available. The organization needs to ponder on the facts that which suits there requirement the best.

This article is going to focus on deployment strategies weighing each method’s pros and cons to get a clear idea of which strategy works best for you. As mentioned earlier there are multiple deployment practices, but we will focus on below-mentioned approaches.

Rolling strategy and canary deployments
Recreate strategy
Custom Strategy
Shadow Strategy
Blue Green Strategy

1. Rolling Strategy and Canary Deployments

The principal idea behind the rolling strategy is to wait for the new pods to become ready. The preparedness of pods is evaluated by a readiness check before taking down the old version. During this period if any serious issue occurs, the rolling deployment can be put on hold.
There is a common practice of employing canary deployments for OpenShift Container Platform. All the new instances are thoroughly tested before replacing them with old versions. If the readiness check does not signal okay, then the deployment is aborted by the team. The check is not an external mechanism; it is inbuilt in the code. The team can always make more stringent checks as per requirement.

When to use
∙ The canary technique carried out when the team is not sure of overall steadiness of the application. To ensure that the new version is working well with the platform it is rolled out in iteration.
Pros
1. Convenient for performance testing.
2. Fast retraction is possible in case of a major issues.

Cons
1. The application rollout is time-consuming.

2. Recreate Strategy

As the name suggests the strategy works on the idea to deploy a dummy version. The new version is deployed when the old version has been closed down. This approach results in significant downtime as both the instances of applications cannot run simultaneously. Let’s look at the situations which are best suited for, pros and cons.
When to use
∙ The approach is ideal for situations before starting a new development task.
∙ When you do not support having version A and version B of your program code operating at the same time.
Pros
1. Easy to put applications together.
2. Application gets revamped.
Cons
1. Downtime of the application is a major drawback.

3. Custom Strategy (A/B testing)

The approach is a little different than the above two strategies discussed above. Instead of rolling out a new version directly a part of the application is introduced to the users. This move is considered more of a business strategy rather than a deployment technique. To make this strategy successful a part of the new application version is rolled out first. Based on the data, statistics, and usage by the end users that part is taken into consideration for final deployment. But for this, we need to make some additional changes in order to distribute the traffic from old to new. Some of them are:
∙         By using browser cookies
∙         Query parameters
∙         Using GPS and IP to get the location of the devices/users.

Pros
1. Negligible downtime as the new version is tested in conjunction with the old version.
2. Traffic among new and old can be efficiently managed.

Cons
1. Requires a strong load balancing mechanism.
2. Troubleshooting can become tricky due to double version management.

4. Shadow Deployment

A shadow deployment principally revolves around the idea of keeping both versions. The old version is not discarded instead the traffic of the old version is diverted to the new version. This way the production is not hampered and the job also gets done. This is particularly effective to test the production load on the new version. Final deployment is done when the application meets all the stability and performance factors.
This approach requires some arrangements to be performed for successful implementation. Let’s consider an example of a payment gateway, one challenge that you can face while implementing is that user might end up paying twice for the same order. This is fairly simple to solve by creating a mocking service you can create a dummy service that replicates the response from the provider.
Pros
1. No separate performance testing required to be done.
2. Minimal impact on the user and production.

Cons
1. The setup can be quite expensive.
2. Additional arrangements like mocking services are required.

5. Blue Green Deployments

Blue-green deployment uses two versions of an application simultaneously. The old version is used is called the green version and the new version is called the blue version. This arrangement requires two configurations. If the testing version clears all the checks then traffic is redirected to a new version. If required, there is also a facility to roll back to the green, version by switching the production back to the previous version.
Pros
1. Switching back and forth between the versions is easy.
2. No versioning issue.

Cons
1. Expensive as it requires managing dual versions.
2. Managing both applications can be tedious task.

Conclusion

There are multiple ways to manage the deployment strategy but it totally depends on the business requirement. So, it is advisable to have in-depth knowledge of your applications, available resources, the end-user requirements, and the cost that it is going to incur on the organization. Considering these options you can go for any of the choices listed above.

The post Devops 2024: Best Popular Deployment strategies appeared first on DevopsCurry.