Handling Updates

Objective

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

The Optimal Zero Downtime Deployment Strategy (ZDD)

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: Is used for more complex deployments and is often paired with mbt MTA Build Tool (MBT) build command to handle multitarget applications (MTAs).

    Code Snippet
    12
    mbt build
cf deploy -f 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:

The figure explains the blue-green deployment.
  1. 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.

  2. 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.

  3. Testing: Once the new version is deployed in the Green environment, you can thoroughly test it without affecting the live Blue environment.
  4. 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.

    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.
    The figure explains the green path.
    • 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.

The figure illustrates the canary deployment.
  • 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.

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.

Implementation:

  1. Redis Configuration:
    • Add Redis service instance details in the mta.yaml file under the resources section.
    • Bind Redis configuration to the Approuter module.
  2. EXT_SESSION_MGT:

    Define the EXT_SESSION_MGT variable in JSON format with the following properties:

    • instanceName (mandatory): The name of the service instance of the storage service.
    • storageType (mandatory): The type of the storage, for example, "redis". Note that if no custom storage driver is used, only "redis" is allowed.
    • sessionSecret (mandatory): A secret to be used to generate a session cookie. Please generate a unique string with at least 64 characters.
    • defaultRetryTimeout: The maximum duration for automatic retries of failed Redis operations in milliseconds. The default value is 2000 ms.
    • backOffMultiplier: A multiplier of the Redis-defined pause that determines the time between consecutive automatic retries of failed Redis operations. The default value is 50.
  3. Important Details:
    • EXT_SESSION_MGT is mandatory for using external session management.
    • Redis is the only supported storage type unless a custom driver is used.
    • Customize settings such as session secret, retry timeout, and back-off multiplier to suit your needs.

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.

Further Reading

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn