Deploying Lambda Updates

Having now stepped through a lot of code, it’s time to cover some of the operational things you need to know about Lambdas. With this in mind, the labs in this section will cover several things. They’ll show how to deploy configuration and code updates. They’ll also show how to optimize the runtime concurrency and memory size settings. And lastly, they’ll benchmark cold starts and show two techniques that minimize them.

Checking Lambda Configuration in the Console

Let’s start by showing some of the Lambda pages in the console. These are useful to know, so that when a Lambda doesn’t work as expected you know where to go to quickly sanity check the configuration.

Step 1: Check the general Lambda configuration in the console

Navigate to the Lambda service in the AWS console, select the “Functions” option on the left, and enter “GetEvents” in the filter text box. Two results should appear, and you should click on the “ConnectedCar_Vehicle_GetEvents_Dev” result and then click on the displayed item in the list.

Once you’ve landed on the pages for this Lambda, select the “Configuration” tab. You should then see the “General configuration” option, as shown below:

The “Timeout” and “Memory” configuration settings you’re seeing on this page should reflect the values defined in the Globals section in the three API templates.

Step 2: Check the Lambda environment variables in the console

Next, select the “Environment variables” option on the left. You should then see the list of variables that are defined in the Globals section of the API templates:

Step 3: Check the Lambda versions and alias configuration in the console

Finally, it’s good to be familiar with where the versioning and alias configuration for Lambdas are found on the console. Click on the “Versions” tab near the top of the page, and you should see all the published versions for this Lambda, as shown below:

We should pause here to provide some background on Lambda versioning. Whenever you deploy new code or update the configuration for a Lambda, it doesn’t take effect in AWS until you explicitly “publish” the changes. Once published, a new version number for the Lambda is assigned, which is what you see above. (Note that if you tear down a stack and redeploy it later, Lambdas in the same region with the same name will get version numbers assigned that are a continuation of those from before, which is why you see version number 26 above).

The integration of an API Gateway endpoint (and HTTP method) with a Lambda requires either a reference to a specific version number or to an alias that’s associated with a version number for the Lambda. In the sample code, we’re automatically assigning the “api” alias to the most recently published versions of the Lambdas. This is why you see the “alias: api” value under the “Aliases” column in the page shown above. This alias is what the API Gateway integrations reference throughout.

To illustrate this relationship between versions and aliases, click on the “Aliases” tab. You should see the one “api” alias that we’ve defined:

Here you can see the alias and its association with the version number. You might recall the “AutoPublishAlias” SAM resource property that’s set for all the Lambdas in the sample code. This property, when set to “true”, automatically creates the alias, publishes the Lambda on deployment, and assigns the alias to the resulting new version.

Deploying Lambda Configuration Updates

Now you’re ready to try deploying some updates.

Step 4: Update the Lambda configuration in VS Code

First, you’ll update the configuration by specifying a different memory size in the resource definition for this specific Lambda. Open the vehicle.yaml template for the OpenAPI deployment and add the “MemorySize: 2048” property to the “GetEvents” Lambda, as shown below:

Step 5: Deploy the Lambda configuration update from the terminal

Next, open the terminal, change to the “/deployment/openapi/scripts/zsh” folder, and run the deploy.zsh script. After a few minutes you should see the stack outputs in the terminal, indicating that the update is complete:

Step 6: Verify the Lambda configuration update in the console

You can verify that the configuration update took effect by returning to the console. Back on the general configuration page for the “ConnectedCar_Vehicle_GetEvents_Dev” Lambda, you should now see that the “MemorySize” property displays a value of “2048”:

Click on the “Versions” tab and you should also see a new version number for the configuration change you’ve just made, along with an updated alias assignment:

Deploying Lambda Code Updates

That was a configuration update. Now let’s do some Lambda code updates.

Step 7: Update the Lambda code in VS Code

Here’s a simple addition to the GetDealers Lambda that’s easy to test, but doesn’t break the OpenAPI endpoint definition. Simply copy the code below and paste it into the GetDealers event handler in the AdminFunctions.cs class, so that it will add the fake dealer item onto the results list:

dealers.Add(new Dealer
{
  DealerId = Guid.NewGuid().ToString(),
  Name = "Fake Dealer",
  Address = new Core.Shared.Data.Attributes.Address
  {
    StreetAddress = "Fake Street Address",
    City = "Fake City",
    State = "WA",
    ZipCode = "00000"
  },
  StateCode = StateCodeEnum.WA,
  CreateDateTime = DateTime.Now,
  UpdateDateTime = DateTime.Now
});                

Here’s what the GetDealers method should look like with this code added:

Step 8: Test the Lambda before the code update

Go back to Postman, where you’ll run the “Admin_API” test collection to populate some test data. You should have the updated values for the adminApi and apiKey global variables already set from the OpenAPI deployment that we did in the previous section. (If you’ve since re-deployed the sample code, you’ll need to set these values again now.)

To start, run the “Admin_API” test collection, which should complete with 25 tests passed, as shown below:

Next, select and run the “Get Dealers” test. Depending on how many times you’ve run the “Admin_API” collection for this deployment, you should have one or more results returned. The example below shows two dealers in the results, both returned from the table data:

Step 9: Deploy the Lambda code update from the terminal

Now, you’re ready to deploy the code update. First, open the config.zsh script for the OpenAPI deployment, and increment the value of the version variable, as shown below on line 9:

In the previous configuration re-deployment, we didn’t change this variable. This meant that the referenced deployment package for the Lambdas was, from the point of view of CloudFormation, unchanged. As a result, the previous deployment updated the Lambda configuration (including its published version number) but didn’t redeploy the Lambda code.

Now we’re incrementing this variable, which gets passed to CloudFormation as a parameter. This parameter sets the file key for the Lambda deployment package in the referenced S3 bucket in the template. The result is that from CloudFormation’s point of view the Lambdas have changed, and so the code is re-deployed.

Note that the value of this template parameter variable is arbitrary. It can be date- or timestamp-based, it can contain software release version numbers, or it can be the name of your favourite restaurant. It just needs a different value for a stack update to also trigger a new code deployment. Note also that the value of this variable has no relationship to the incremental Lambda version number that we’ve seen in the console.

Once the version variable has been updated, you’re ready to run the deployment scripts. In the configuration update we did earlier you only had to run the deploy.zsh script. Now you have code changes to deploy as well, so start by running the clean.zsh and build.zsh scripts in sequence. Once these have executed, check in your S3 deployment folder. You should see the Lambda deployment file with the updated value of the version variable appended to the file name, as shown below:

Now, run the deploy.zsh script. As always, when you see the stack outputs displayed in the terminal, the script has finished executing:

All the Lambdas in the sample code reference the same deployment package, which means they all get their versions incremented when this package is updated. So if you take another look at the versions for the “ConnectedCar_Vehicle_GetEvents_Dev” Lambda, you should see an added version number, as shown below, even though the code and the configuration for this Lambda hasn’t actually changed:

Step 10: Re-test the Lambda after the code update

Now you can run the “Get Dealers” test again in Postman. This time you should see the extra hard-coded fake dealer added to the results, showing that the code update has been successfully deployed: