Blue/Green Deployment in AWS Lambda

Blue Green Deployment is just like we deploy two versions of our application, one is the stable version, and another is a new feature or bug fix let's say, forwarding a certain percentage of traffic to the second version as well in production to ensure that everything is working fine.

The Blue environment represents the currently active version of the Lambda function. In contrast, the Green environment is a development version of code where new changes are deployed and tested. Once the changes in the Green environment are verified, green deployment will be promoted to Blue, enabling seamless and zero-downtime deployments. With Blue Green deployment we can test our application with real-time users, without replacing the production workload completely.

Architecture

Lambda Blue Green Deployment involves two services API Gateway and AWS Lambda, we'll use API Gateway's Lambda integration with an alias to shape it as Blue-Green Deployment, here Lambda Function Consists of two different but identical environments called Blue and Green respectively.

These two environments are two different lambda versions, mapped to a single Lambda alias, a pointer to one (or another additional weighted version) version of the Lambda function. Lambda Versions are revisions of our code, we can create new versions of code without disturbing the production workload.

API Gateway: Allows us to specify a lambda alias as a target, so we can specify a lambda alias that has a Blue-Green Deployment setup configured, i.e. routing traffic to two different environments using the single API.

Blue Deployment: It's the primary Deployment which is stable, and being used as production.

Green Deployment: It's a kind of clone version, but it has additional changes in it, we can route the traffic to the Green deployment so that if any issues are there in the Deployment we can fix them and then promote it to Blue, so that reducing the chances of failures in production environment.

Approach

• Create an Alias to Maintain Blue-green Deployments
• Publish a new version (Blue)
• Map new version to Alias
• Make some changes in Code, then publish another version (Green)
• Point alias to the new version (Green), weighted at some X% (Blue version at (100-X)% of traffic)
• Verify that the new version is healthy
• Optionally we can implement automatic promotion of green to blue.

Canary vs Blue-Green deployment

When it comes to deploying software updates or new features, two popular strategies that organizations often employ are Canary Deployment and Blue-Green Deployment. Both approaches aim to minimize downtime and mitigate risks during the deployment process, but both have different characteristics and will be used for different purposes.

 Canary Deployment

Canary Deployment is a technique where a new version of an application is gradually rolled out to a subset of real users, unlike dummy users we use in a testing environment, while the majority of the traffic continues to be served by the stable version itself. The process involves routing a small percentage of traffic to the new version and monitoring its performance, and user experience. If the new version works successfully without any issues, more traffic is gradually shifted towards it.

Blue-Green Deployment

Blue-Green Deployment involves running two identical environments, referred to as "blue" and "green." The stable version of the application called as blue environment, while the new version is deployed and tested in the green environment. Once the green environment seems stable and looks ready for production, the traffic is routed from the blue environment to the green environment, effectively switching the environments, this process is called promoting the green to Blue.

Challenges in Blue-green deployment

Infrastructure Overhead

Implementing Blue-Green Deployment requires maintaining two identical environments, the "blue" and "green" environments. This can lead to increased infrastructure overhead, including the cost of running and managing duplicate environments, as Lambda is a serverless, pay-per-use model, this might not be a much concern

Data Migration

In scenarios where the application relies on a database or other persistent data storage, migrating data from the blue to the green environment can be challenging. Ensuring data consistency and synchronization between the two environments requires careful planning and execution, we do not place such things in the Blue Green deployments model.

Rollback Complexity

While Blue-Green Deployment aims to simplify rollback by instantly switching traffic from the green to the blue environment, there can still be complexities involved. The rolling back may require reverting database changes, undoing configuration updates, or handling data synchronization issues, depending on the specific deployment scenario.

Why Blue-Green Deployment?

1. Zero Downtime: Blue-Green Deployment eliminates downtime during the deployment process since the switch from the blue to the green environment is instantaneous. This ensures uninterrupted service availability for users.
2. Fast Rollback: In case any issues or failures occur during the deployment of the new version in the green environment, rolling back to the stable version in the blue environment is quick and straightforward.
3. Reliable Testing: Blue-Green Deployment allows comprehensive testing of the new version in an environment that mirrors the production setup. This ensures a higher level of confidence in the stability and compatibility of the new version before directing user traffic to it and many more...

Let's do the Blue-green deployment practically.

Steps To Configure Blue-Green Deployment

Create a Lambda Function

Create a lambda function with Python runtime.

Publish a New Version

We need to create a new version by navigating to the Versions Tab, giving it a name, and clicking on Publish.

Create an Alias

AWS Lambda Aliases is a good feature actually, we maintain multi-stage environments using Lambda Aliases for a few projects, and with this, we can invoke the specific versions of a lambda with alias URI,

Update the lambda handler as below and follow the below steps to create an alias with it.

import json

def lambda_handler(event, context):
    return {
        "statusCode": "200",
        "body": "Hello From Blue Deployment",
        "isBase64Encoded": False
    }

• Open Lambda Function
• Navigate to Aliases Tab
• Create an Alias by choosing a proper name and description
• Choose version.
• We'll configure the secondary weighted version in the below steps.

Configure Weighted Alias

In Lambda Alias we can configure weighted alias so that we can forward traffic to another version of lambda within the same Alias.

Update the lambda handler as below.

import json

def lambda_handler(event, context):
    return {
        "statusCode": "200",
        "body": "Hello From Green Deployment",
        "isBase64Encoded": False
    }

To configure the weight for the alias, follow the below steps:

• Navigate to the Aliases page
• Choose Edit option
• Under the Weighted alias section, choose your secondary version to forward traffic.
• Set weight in percentage (remaining will be forwarded to the main version)

 Configure API with Lambda Alias

 We use API Gateway to integrate and test our blue-green deployment, In API Gateway we can also configure a lambda alias instead of the lambda function, which will forward traffic to the alias (weighted alias), so you will get a response from both versions of the lambda configured for the Alias based on the weights.

•  Open API Gateway API -> Method -> Integration Request.
• Choose Integration Type 'Lambda Function.
• Under Lambda Function: set the Lambda Alias Arn

 Here you can observe we're integrating the Lambda Alias arn which is in the format of arn:aws:lambda:<region>:<account_id>:function:<function_name>:<alias_name>, so that the API Gateway requests will be served from this alias i.e two different lambda versions mapped in the alias.

 Test The Blue-Green Deployment

Now it's all done, you can invoke your API, and you can see the responses come from two different lambda versions at various invocations, depending on the weightage you've given.

By following the above-mentioned processes we can achieve the blue-green deployment by using AWS Lambada.