Overview
AWS Lambda is a serverless compute service which lets you run code without provisioning or managing servers. With Lambda, you can run code for virtually any type of application or backend service – just set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.
Amazon API Gateway is a fully managed service that allows you to create, publish, maintain, monitor, and secure APIs at any scale. With API Gateway you can create an API that acts as a “front door” for AWS Lambda functions.
Together AWS Lambda and API Gateway are commonly used in N-Tier architecture applications, for example, the front end UI developed in Angular, ReactJS or Vu.js and calls API gateway endpoints which eventually triggers Lambda functions.
The benefits of using N-Tier architecture is that you don’t have to manage any servers or EC2 instances, you can deploy your app on AWS S3 and rest is taking care by AWS API gateway and AWS Lambda as shown in the slide.
Another benefit is to debug or deployment of new features is relatively easier as compared to other architectures.
Problem
The problem or challenge is when working in multiple environments with Lambda functions. Typically organizations have Development, QA and Production environments. So how would you implement new features or changes to your existing Lambda functions without impacting when one function is currently running in Production or QA?
One solution could be to have different AWS accounts but that also add some administrative overhead.
Solution
To solve the above problem AWS Lambda Versioning and Aliases comes into action. Using versioning in AWS Lambda, you can publish one or more versions of your Lambda function and work with different variations of your function in your development workflow, such as Development, QA or Production.
AWS Lambda also supports creating aliases for each of your Lambda function versions. Conceptually, an AWS Lambda alias is a pointer to a specific Lambda function version.
To learn more about AWS Lambda versioning and aliases check out the AWS documentation
In our example, we have a single AWS Lambda function behind AWS API Gateway. The API gateway has 2 different stages deployed named as DEV and PROD. By calling these stages you will see a different Lambda function response from a single Lambda function respectively.
This will allow us to test the API and Lambda function in DEV environment independently of Production API.
We have to do the following
- Create Versions and Aliases in AWS Lambda Function
- Create Dynamic Resources in AWS API Gateway
- Create Deployment Stages and Variables in AWS API Gateway
- Test the API
To summarize, when you call the DEV staged API endpoint the function would “Hello from Lambda World” and in case of PROD endpoint the function would return “Hello from Lambda”
The following slide gives an overview of our example
Versioning and Aliases in AWS Lambda Function
As shown in the slide, we have 2 different versions names 1 and 2 respectively of the same lambda function called hello-lambda.
You can create a new version of lambda function by clicking Publish New Version
Following is the version 1 we will be using for our PROD API
Following is the version 2 we will use for our DEV API
Similarly, you can create aliases by click Aliases, in our case we have dev and prod aliases defined which point to version 2 and version 1 as shown in the slide
Dynamic Resources in AWS API Gateway
Once we have versions and aliases defined you can call your Lambda function using the following method
mylamda-function:my-alias
e.g. hello-lambda:prod or hello-lambda:dev
In order to make it efficient, we need to pass the aliases dynamically so in case of any change our APIs aren’t impacted.
You can do this using Stage Variables in AWS API Gateway, in our case we are passing the alias to Lambda function value by ${stageVariables.env}. On runtime, AWS API gateway would replace the value of the “env” with the value we define.
Note: When defining Stage Variable in the resources you need to add permissions to use stage variables. API gateway would prompt you to run the following command
You need to run this command on AWS CLI with a proper setup as many times as stages in our case we had to run this twice with dev and prod
Deployment Stages and Variables in AWS API Gateway
You also need to define multiple stages in AWS API gateway as shown in the slide we have 2 stages defined as dev and prod
Click on the Stages then click on Stage Variables and enter the name of your variable and value you like to pass on this API endpoint. In our case, we have variable defined env which is we are using in our Lambda Integration point (see the previous paragraph)
Stage Variable for DEV
Stage Variable for PROD
Test the API
Copy the API endpoint from the stages as shown in the slide
Now test the dev stage endpoint in Postman the API would return “Hello from Lambda World”
Now try the prod stage endpoint, you will see the “Hello from Lambda”
Summary
AWS Lambda Versioning and Aliases are powerful features allow us to develop multiple versions of the same function and use for different use cases. AWS API Gateway Stage variables provide us to pass dynamic URLs and resources to avoid duplicates and complexity when developing your APIs.
Hope you find this post useful, please leave a comment for any questions or suggestions.
About DataNext
DataNext Solutions is a US based system integrator, specialized in Cloud, Big Data, DevOps technologies. As a registered AWS partner, our services comprise of any Cloud Migration, Cost optimization, Integration, Security and Managed Services. Click here and Book Free assessment call with our experts today or visit our website www.datanextsolutions.com for more info.