AWS Lambda Automated Deployment

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 –

aws1

The iOS/Android/Web App invokes the AWS Lambda function through the ARN with appropriate permissions set via the IAM role as shown below:

aws2

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:

aws3

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:

 


{
"name": "Project name",
"description": "Project description",
"role": "Lambda execution IAM role",
"timeout": 300,
"environment": {"environment": "dev"}
}

view raw

project.json

hosted with ❤ by GitHub

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:


{
"description": "Function description",
"hooks": {
"build": "pip install -r requirements.txt -t ."
},
"environment": {
"folder": "user"
}
}

view raw

function.json

hosted with ❤ by GitHub

      • 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:

aws4

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.


 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s