As I detailed in a previous blog post, I’m continuing to update the Linux Academy AWS DevOps Pro certification course. The course has three new sections (and Lambda Versioning and Aliases plays an important part in the Lambda section):
- Deployment Pipelines
- AWS Lambda, and
- AWS API Gateway
As well as six new hands-on, interactive Labs.
AWS Lambda and Serverless Concepts
In AWS, we work a lot with infrastructure: VPCs, EC2 instances, Auto Scaling Groups, Load Balancers (Elastic, Application, or Network). And of course, with CloudFormation we deal with that infrastructure as code. Those json or YAML templates are literally code. AWS Lambda is often used to work closely with CloudFormation as kind of a utility knife that can be used to perform tasks that are just not available out of the box with CloudFormation. Now to be clear, it is not Lambda’s sole purpose to work with CloudFormation, but it is certainly a common use case. Chances are that if you work in AWS long enough you will encounter use cases that call for the implementation of Lambda Functions. And the possibility exists that you may encounter environments that are completely serverless. In these cases, you provide your Lambda Functions to AWS and they worry about the rest. You can be sure that there are servers tucked away in the cloud somewhere running your Lambda Functions, but they are of no practical concern of yours. You are not charged for that infrastructure. You are only charged for how long your Lambda functions are running. So in a serverless environment, the infrastructure is completely removed from your equation. Again, the CloudFormation mantra is infrastructure as code. Well with Lambda, the infrastructure, for all intents and purposes, is removed and you are just left with code.
Software Deployment Workflows and Versioning
As DevOps Engineers, we are required to wear several different hats. And if we are working with Lambda we need to be adept when we put on our Software development and deployment hats. So you’re going to follow software best practices and a typical development/deployment workflow would be to have development, beta, and production environments. There are no hard fast rules on this. You could for example also have a test environment. But the main point is that with different environments, you are going to have different versions of your Lambda functions deployed to these environments. Can we easily version our Lambda functions? Absolutely (in a Rocky Balboa voice).
By using versioning, we can better manage our in-production function code in AWS Lambda. When you use versioning in AWS Lambda, you can publish one or more versions of your Lambda function. A key point to all of this is that each version of your Lambda function has its own ARN, and most importantly, a published version of your Lambda function is immutable. In Layman’s terms, you can’t change a published Lambda function! On the surface that seems pretty restrictive. If I can’t change a published version, what hoops do I have to jump through to come up with another version that is only slightly different from my published version? Have no fear. There is one readily available version of your Lambda function that you can change and it is named Version $Latest. This is the most recent version of your function and you can make changes to it and publish a new version based on those changes that you make. And when you first create a Lambda function, this is the only version that you have:
The screenshot above shows the Lambda management console with a newly created Lambda function. By clicking the ‘Qualifiers’ dropdown, we are presented with the Versions for our Lambda function and the Aliases (which we will talk about momentarily). Now if we want to publish a new version of our Lambda function, we would simply make the changes we want to the function, go to the ‘Actions’ dropdown and select ‘Publish new version’:
Now at this point you might be thinking that the $Latest version and your new version (version 1) would be the same. You would be correct. But remember, only the $Latest version can be changed. So when you decide you need a second version, you would make changes to $Latest and then publish that new version (version 2). Your latest version will then match version 2 until you decide to make further changes to your $Latest version. In this way, you can create as many versions as you like and all your numbered versions will be different from each other.
Let’s assume that version 3 is our Prod version. We have identified a change that needs to be made in our code. We would then make the updates to $Latest and publish a new version. This new version could initially be in our dev environment. We don’t want to dump it right out to prod and hope for the best. We could do some testing on it in dev, move it to beta, test some more, and then finally move it out to our prod environment.
Now we also saw in the Lambda console that there is support for aliases. What can we do with aliases? AWS Lambda supports creating aliases for each of your Lambda function versions. The alias is simply a pointer to a specific Lambda function version. Each alias also has a unique ARN. One key difference between aliases and functions is that you can change aliases. You can change aliases to point to different versions of your functions. Think about the power at your hands with that capability! If you have a prod alias, for example, you can change that alias to point to a different version of your function. That function magically becomes your prod function just by pointing the prod alias to it. It’s a little more complicated than that, but not too much. Remember, all Lambda functions need an event source, whether it be an S3 bucket, an API, a DynamoDB table or any other event source. Let’s assume that we are working directly with our Lambda function. So in our event source (S3 bucket for example), you identify the Lambda function ARN that S3 can invoke (an example invocation would be uploading a file to S3 triggers our Lambda function). The problem is that our Lambda function versions are immutable! So every time we promote a version to prod, we have to go to S3 and enter the new ARN. So how can we abstract the process of promoting Lambda functions, so that we don’t have to change our invocation settings in S3 every time? We can use aliases! In S3, we can enter the alias ARN for our prod alias. If we have a new version for our Lambda function that we want to be our prod version, so what! We can change our prod alias in Lambda to point to the new version. The configuration in S3 never has to be touched. Prod will always be prod. Whatever function we point our prod alias to will be our prod function.
So that’s a look at how we can use Lambda function versions and aliases to simplify and streamline our function deployment process. The easier and more flexible this process, the less prone to error it becomes.
I have been updating my AWS DevOps Professional Certification course and Lambda versioning and aliases is one of the new areas of focus. But there is much more that has been added and updated, so check out the updated AWS Certified DevOps Engineer – Professional Level course here!