[Version: Alias] — The safer way to deploy your AWS Lambda Function
To emphasis that, this is an older version of the article explaining the AWS Lambda Function. Which I think it couldn’t be as clean as I thought to bring out the core content for the idea. If you do interested, still, may reach out this latest article.
— Simple Walkthrough
When we come across software or architecture development using Serverless computing services in AWS, probably Lambda will be a good option. AWS Lambda along with other services like API Gateway, Amazon S3 as well as DynamoDB can serve as the basic needs for us to run a website.
Better still, a Serverless approach can save up time and effort managing server(s) and operating system(s) that required to set a site up. With AWS Lambda, we only pay for the compute time it’s consumed. In other words, there is no charge upon period when your code is not RUNNING.
But… Why Do We Need Lambda Versioning?
It’s no doubt, the cost of software/system failure can bring serious repercussions to your business. Deployment of a buggy function not only will it affects the particular behavior of the system, but as well it brings bad impressions directly to your consumers.
You lose your fame, so do your consumers’ trust.
Hence, we need a proper way to deliver our well-tested software pieces. Be it in a development or production environment, we need them tested!
To begin the story, let’s set an introductory remark of what we had been told, the so-called “AWS Lambda versioning”.
Jumping straight into the topic, say you have already an existing Lambda functionA.
“You Edit The Code”
You have some enhancements for the functionA and ready to deploy.“You Save”
Be it the functionA updated through aws cli commandaws lambda update-function-codefrom local / EC2 instance;
or being manually updated through zip file upload.
“You Publish”
Upon a publish event, you will be aware that the Lambda function will now has a version number of 1 incremental from its original. Each Lambda function’s version has a unique Amazon Resource Name (ARN). After you publish a version, it can’t be changed.
It makes sense for math too : version1, version2, version3, ……version n!
Another Scenario :
When there is no code change as compared to the current version of Lambda function…..
No publish event occurs…
Yup.
You’re right.
No change.
So… no publish required.
You’re smart.
We have now updated the Lambda FunctionA twice:
Version 1: return { “message” : “Hello World.”}
Version 2: return {“message” : “Hello Boy.”}
Version 3: return { “message” : “Hello, it’s me.”}
Using the versioning method allows us to manage our in-production function code in AWS Lambda better. We can publish one or more versions for a particular Lambda function.
As a result, you can work with different variations of your the same Lambda function in every single stage of your development workflow, say: development, test, and production.
“Hold on! But do you know what is an Alias for Lambda?”
To understand it in a simple way, the Alias serves as a pointer that points to a specific version of your Lambda code. We can create more than one alias for a single Lambda function.
And upon the creation of an alias, we are required to assign it to a specific version.
Let’s say ...
We have now created three aliases, pointing to different versions of Lambda FunctionA:
The Aliases :
PROD → Version 1
TEST → Version 2
DEV → Version 3
Please observe below as an example of successful relations between versions & aliases for a Lambda function.
- DEV→ Version 18
- PROD → Version 19
We will need other AWS services to be integrated before we can invoke it.
Let’s take API Gateway as an example event source who is responsible to invoke our Lambda functionA.
Let’s say …
We have now created 3 different endpoints in a resource of an API Gateway, serving dev, test and production use case respectively:
The Endpoints:
/authorization/validate_prod
/authorization/validate_test
/authorization/validate_dev
Reminder:
We have now 3 aliases for Lambda functionA created, we are free to use one of those.
We will be doing these actions:
We point all three endpoints to subscribe to their individual alias;
Subscribing:
/authorization/validate_prod → @ PROD
/authorization/validate_test → @ TEST
/authorization/validate_dev → @ DEV
We do normally attach our lambda function name in API Gateway service to integrate them. This will always return us the reference to the latest version of the lambda code.
However, to point to specific alias of a function, it can be achieved as simple as doing an action like below.
Save and publish your API Gateway for the new change and we are almost there!
Reminder: PROD → Version 1
The API Gateway with three endpoints below are now subscribing to Lambda FunctionA with three different aliases:
/authorization/validate_prod → functionA:PROD
/authorization/validate_test → functionA:TEST
/authorization/validate_dev → functionA:DEV
Another HeadsUp!
PROD → Version 1 (It’s a stable version, currently in live)
TEST → Version 2 (It’s a developer tested version, propagating UAT)
DEV → Version 3 (it’s a version, just Built)
“Story Time : Safe Deploy ….”
- Both @Test & @PROD version codes are having the exact same environment setting — production .env
- While currently @TEST has an enhancement on top of Version 1, ready to deploy.
- Say we have UAT on the production environment utilizing endpoint authorization/validate_test [which is using TEST alias → Version 2].
- Finish UAT with Test Ready feature in Version 2 code, we are free to do our deployment of Lambda in a blink.
- The process is fast and safe. We only need to take action like below:
Edit From Lambda FunctionA‘s Alias:
From
PROD Alias → Version 1
Change PROD Alias version to :
PROD Alias → Version 2
Everything is GOOD to go !!
Conclusion
Above are some suggestions of having a safer approach to deploy an AWS Lambda function from dev → test → production with :
“AWS Lambda Versioning : Version & Alias”
I hope this article helps give you an idea regarding the AWS Lambda versioning management. Cheers !!
