Handling Updates

Objective

After completing this lesson, you will be able to implement the optimal zero downtime deployment strategy tailored to your specific use case.

The Optimal Zero Downtime Deployment Strategy

Introduction

Your software company is committed to providing customers with the latest features and improvements without disrupting their experience. Unexpected downtime is not an option. In this lesson, you will discover how to leverage zero downtime deployment (ZDD) practices to ensure that your applications remain highly available and experience seamless updates.

Motivation

In today's fast-paced digital landscape, your customers demand constant access to your applications, regardless of updates, upgrades, or unforeseen issues. Downtime, whether planned or not, can result in significant financial losses, damage to your brand's reputation, and the loss of valuable customers. To remain competitive and deliver innovative solutions without disruption, minimizing downtime is crucial. Zero downtime deployment (ZDD) strategies are essential for mitigating these risks and ensuring a seamless user experience.

Zero Downtime Deployment Strategies

cf push / cf deploy

These are the primary commands used to deploy most applications in the Cloud Foundry environment:

cf push: Uploads your code and dependencies to Cloud Foundry, which then identifies the necessary buildpack, compiles your code, and creates a droplet (a package containing your application).
cf push my-app
cf deploy: This is used for more complex deployments and is only used with mbt MTA Build Tool (MBT) build command to handle multitarget applications (MTAs). It does not work with manifests used in cf push commands.
Code Snippet
```
12
mbt build
cf deploy mta_archive.mtar  
```
Benefits: Easy and efficient for quick deployments of small applications.
Drawbacks: While cf push and cf deploy are both suitable for simple deployments, cf push specifically lacks built-in zero-downtime capabilities, making it unsuitable for production environments requiring continuous availability.

Rolling App Deployment

In rolling deployments, instances of the old version are gradually replaced with instances of the new version. This ensures that some version of the application is always live.

cf push APP-NAME --strategy rolling

Benefits: Minimal downtime. Ability to roll back if issues arise.
Drawbacks: Potential for latency as versions switch. Rollbacks can be time-consuming due to Stateful applications and database schema changes.

Blue-Green Deployment

Blue-green deployment is a powerful technique for minimizing downtime and reducing risk during application updates. In this section, you'll explore the essentials of implementing a blue-green deployment strategy of multitarget applications using Cloud Foundry. The process is straightforward. Here’s a simplified overview:

Blue Environment: This is your current live production environment. It's up and running, serving all your user traffic.
cf deploy <your-mta-archive-v1> --strategy blue-green
This command kicks off a blue-green deployment for a fresh application, beginning with no previously deployed MTA. It fires up the appname-idle applications, making them accessible at specific URLs. After confirming that these appname-idle instances are running smoothly, the command renames them from appname-idle to appname, finalizing the deployment process and making the new version live.
Green Environment: This is the idle environment where you deploy the new version of your application. It's identical to the Blue environment, but it's not serving any traffic yet.
cf deploy <your-mta-archive-v2> --strategy blue-green
This command kicks off a blue-green deployment by renaming current applications to "live" versions and launching new "idle" versions. The idle versions of the apps start and become accessible at specified URLs. The deployment then moves into a testing phase where you can test the new version before making it final. You've got the option to either continue or cancel the deployment using specific commands. If you'd like to bypass the testing phase, just use the --skip-testing-phase option.
Testing: Once the new version is deployed in the Green environment, you can thoroughly test it without affecting the live Blue environment.
Switch: When you're confident that the new version is working perfectly, you can switch the router so all incoming requests now go to the Green environment. And there you have it! The Green environment becomes the new live environment. The following command with the right operation ID is also printed from executing the last cf deploy command.
cf deploy -i <operation ID> -a resume
This command does the following:
1. Maps the productive routes to 'web-idle' and 'backend-idle'.
2. Deletes the temporary routes for 'web-idle' and 'backend-idle'.
3. Restarts 'web-idle' and 'backend-idle' with productive route configurations.
4. Rename 'web-idle' and 'backend-idle' to 'web' and 'backend'.
5. Deletes the previously productive 'web-live' and 'backend-live' applications.
- Benefits: '--strategy blue-green' command simplifies blue-green deployments by automating the entire process, including testing and cleanup, reducing manual steps and errors. It enhances resource efficiency and offers an easy rollback mechanism, ensuring a streamlined and reliable deployment experience with minimal downtime.
- Drawbacks: Handling user sessions and data consistency during the switch can be challenging, especially in stateful applications, increased resource consumption due to duplicate environments.

Canary Deployment

Canary deployment is a deployment strategy that involves gradually rolling out a new version of an application to a small subset of users or servers in a production environment by initially directing a small percentage of traffic to the updated version while keeping the majority of traffic on the stable version.

Benefits: Real-world testing and validation before full rollout, easier identification of issues in production, and the ability to quickly revert to the stable version if necessary.
Drawbacks: Rollback might be complex for stateful applications and database schema changes, and necessitates careful planning to ensure forward compatibility and effective observability.

You deploy a new version of your app with the command. cf push <app_name> --strategy canary
Now one app instance is updated with the new version. Also the traffic is routed to this app instance but the traffic is also routed to the app instances with the old version. You can get routed to the cannary deployed app instance with the HTTP Header field:"X-Cf-Process-Instance":"<PROCESS_GUID>:<INDEX>"
After testing you can update the app instances with the old version to the new version with the command.cf continue-deployment <app_name>

Leveraging Redis for User Session Management in Approuter

When an active application is replaced by an idle one, the in-memory data is lost, resulting in user session data being cleared. To avoid this, Approuter enables external session management using Redis. This allows session recovery if the original Approuter instance crashes, ensuring continuous user session management.

For more detailed configuration steps, refer to the official SAP Approuter documentation

Choosing the Right ZDD Strategy

The ideal ZDD strategy depends on several factors:

Application Criticality: Mission-critical applications demand minimal disruption, often favoring blue-green deployments. Noncritical applications can tolerate more flexibility, allowing for faster updates with rolling or canary deployments.
Resource Constraints: Limited resources might make resource-intensive blue-green deployments less feasible. Rolling or canary deployments are often more cost-effective in such cases.
Risk Tolerance: Risk-averse organizations prioritize safety with blue-green deployments. Organizations open to some risk can leverage canary deployments for real-world testing and early issue detection.
Deployment Complexity: Simple deployments using cf push or cf deploy can be quick but will cause temporary downtime. Consider these commands in the context of your broader ZDD strategy.

Summary

Zero downtime deployment (ZDD) is a crucial practice for modern software development, minimizing disruptions to users and ensuring continuous access to applications. In this lesson, you've discovered various ZDD strategies, including rolling updates, blue-green deployments, canary deployments, and user session management with Redis database. By understanding these strategies and considering factors like application complexity, risk tolerance, and resources, you can select and implement the most effective ZDD strategy for your specific needs.