Objective
The document details the steps to build, deploy and maintain different versions of lambda functions across various product stages such as dev, test, stage and prod across multiple AWS accounts.
AWS Lambda Versions & 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. When you use 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 and once it is published manually through console or through AWS Command Line Interface or through AWS SDKs, a new version will be created automatically with auto incremented version number.
While publishing the lambda, we can additionally set an alias to the lambda to point to the stage to which 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 can invoke 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 version of the iOS App which would still need to invoke older lambda functions. Provided 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 need to 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.
[gist https://gist.github.com/palasgaonkar-vishal/93dcead49c7f2c882171e7b5654b7c87]
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 will include function level overrides as well variables pertaining to the specific function.
[gist 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, with 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 while also supporting 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.
