Objective
This blog details the steps to build, deploy and maintain different versions of Lambda functions across various product stages such as development, testing, staging and production on multiple AWS accounts.
AWS Lambda Versions and Aliases
AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically.
By using versioning, you can manage your in-production function code in AWS Lambda better. With versioning in AWS Lambda, you can publish one or more versions of your Lambda function. As a result, you can work with different variations of your Lambda function in your development workflow, such as development, beta, and production.
By default, developers work on the Lambda that is pointing to the $LATEST version. Once it is published manually through a console or through AWS Command Line Interface or through AWS SDKs, a new version is created automatically with an auto-incremented version number.
While publishing the Lambda, we can additionally set an alias to the Lambda to point to the stage where we want to publish the Lambda changes.
A simple workflow of publishing a lambda to Dev instance is shown below –
The iOS/Android/Web App invokes the AWS Lambda function through the ARN with appropriate permissions set via the IAM role as shown below:
Lambda Alias Versioning
In addition to the versioning maintained by AWS for each Lambda, there is a need to version the alias as well since there could potentially be older versions of the iOS app which would still need to invoke older Lambda functions. The schematic below explains alias versioning:
Apex Serverless Deployment Tool
Apex is the serverless automation tool that provides a way to build, publish and maintain AWS lambda functions. The lambda functions must be defined as per the Apex standardized folder structure as described below:
Lambda Folder Structure (Apex Standards)
project.json – configuration file that contains global variables that will be applied across all lambda functions included under the project:
https://gist.github.com/palasgaonkar-vishal/93dcead49c7f2c882171e7b5654b7c87
https://gist.github.com/palasgaonkar-vishal/9dbdbd0c4a4d596809b76cc494c3618f.js
- Functions (Parent Folder) – parent folder which describes the project under which all Lambda functions are defined.
- hello-world – child folder containing the Lambda function
- main.py – AWS Lambda code.
- function.json – configuration file that includes function level overrides as well variables pertaining to the specific function:
- hello-world – child folder containing the Lambda function
https://gist.github.com/palasgaonkar-vishal/9dbdbd0c4a4d596809b76cc494c3618f
-
-
- requirements.txt – package dependency list which will be downloaded, built and zipped along with Lambda by Apex function.
- event.json – test input for the Lambda function.
-
Automated Deployment with Jenkins and Apex
Jenkins is an open source automation server which helps to automate the non-human part of software development process via continuous integration and facilitating technical aspects of continuous delivery.
Bringing it all together, we can configure each code submission to GitHub repository to trigger a build in Jenkins to invoke APEX Serverless commands to publish the Lambda function with the appropriate alias.
The schematic below describes the process:
Conclusion
By combining multiple tools such as Apex and Jenkins we can setup an automated process to deploy code committed to GitHub repository to various environments, spread across multiple AWS accounts. It also supports backward compatibility of mobile apps which can have users spread across multiple versions of the app.
This automated deployment process frees up developers from worrying about complicated deployments of a serverless project and focus on what’s most important – building a world class app.
