Serverless Deployment Preferences
The core principle of serverless work is that the platform is responsible for receiving events, not your code. The network socket (server) belongs to the hosting provider, not to your function. But also your Lambda versions. Each CloudFormation deployment, creates a new version. When we deployed the expenses stack, SAM wired the API gateway to our Lambda function to always use the $LATEST version. That’s OK for a simple case, but it might be problematic for backwards incompatible deployments in the future. Updating a distributed architecture is not instantaneous. We don’t want the API somehow to get updated first, then send a new version of an event to an older version of the function that does not know how to handle it.
You can define what it means for a deployment to be problematic. For example, split the users into a control group working with the existing code and a test group that sees the new version, then automatically check for Lambda errors or time-outs. That way you can quickly prevent integration problems that were not detected during testing. Alternatively, run the experiment over a longer period of time and measure user behaviour, such as funnel conversion or purchases. For example, if the unit and integration tests passed, but something unexpected is causing users to buy less with the new version, would it not be smart to automatically roll back and protect revenue, and alert someone to investigate it?
And now guess what the "Sauf Pompiers" SARL folks want you to do, and enable?
SAM has a convenient shortcut for publishing configuration versions, and for ensuring that event sources (such as API Gateway) are correctly configured to request that particular version. All you need to do is add AutoPublishAlias to the function properties in template.yaml. When SAM publishes a configuration version, it will automatically create or update the specified alias to point to that version.
Important. Lambda and API Gateway charge for requests, not for the number of environments, so there is no special cost to keep an old copy around while the new one is being created.
AWS CodeDeploy, another Code- product can modify the routing configuration over time to gradually switch between several versions of code and infrastructure. CodeDeploy can, for example, show the new version of an application to only 10% of the users and wait for a short period while monitoring for unexpected problems. If everything looks OK, CodeDeploy can expose the new version to everyone, and shut down the old version. On the other hand, if the new version seems to be problematic, CodeDeploy will just roll back the experimental version and move all the users back to the old infrastructure. Reassigning aliases to published configuration versions is very quick, much faster than a redeployment.
Interesting fact. By default, an AWS account has 75 GB available for storing Lambda functions, including the code for all published versions. SAM will not automatically clean up old versions for you, so you may need to periodically do some housekeeping if you deploy large packages frequently.
AWS SAM enables us to utilize the CodeDeploy on a per-function level using a Properties field called DeploymentPreference.
Tasks
Add it to all 3 of your functions and make it a Linear 10% deployment every minute. You can read about that here and here is a more Documentation First approach.
Change the codebase by commenting out the code for each function and just return a "hello world" text. Don't forget to add the appropriate API GW response format.
Deploy it and try every minute, using Postman or some other tool. You should see a percentage change in the responses you receive from your API each minute.
Revert or try other options.