Let’s talk about the mayor deployment strategies for serverless applications and how AWS helps you to do this.

There are 3 main strategies for deployment in serverless applications: All at once, Linear and Canary. We have been doing all at once deployments always in all my videos. Basically, if you didn’t guess all at once is to shift all the traffic at once from the old environment to the newly deployed environment.

Canary deployments are when you specify the percentage of traffic we want to shift and the time we want the deployment to last. We can say that we want it to last 30 mins and with 10% of the traffic, this means that during 30 minutes we will have 10% of the traffic and after that time passed the rest 90% of the traffic will be shifted.

Linear deployments are changing the amount of traffic split to the new version incrementally according to a percentage that is provided when configured. So we can say that we want to increment the traffic by 10% every 5 minutes. Or total deployment will last 50 minutes, and little by little the amount of traffic that will be shifted to the new version will increase.

Canary and linear are more complex strategies and to perform them you need to add some logic to your deployment tool. You could build it yourself as well but that would be a lot of work. There are many tools that provide canary and linear deployments.

In AWS every Lambda functions can have any number of versions and aliases associated with them. Versions are immutable snapshots of a function, includes codes and configuration. It is a good practice to publish a new version every time you update your function code. When you invoke a specific version, you are guaranteed to get the same code and configuration.

Versions can be used effectively with an alias. An alias is a pointer to a version. Alias has a name and an ARN, and you can use that ARN to invoke the function in the right version. One basic deployment strategy in serverless is to update your function code in production, publish a new version, invoke the version directly to run your integration tests against it, and after everything looks good you can flip the alias that your production uses to point to the new version. Now traffic will start shifting instantly from the old version to the new version. This is quite tedious work.

Usually, in production, we want automated deployments and controlled traffic shifting. For that, we need to use some kind of tool. AWS provides CodeDeploy that is a managed service that helps you to deploy your serverless applications with different deployment strategies, also it lets you monitor the deployment and have alarms and can trigger the rollback if something is wrong.

So CodeDeploy will help you to deploy your new versions of lambda functions using different strategies, like linear or canary. It also can define pre-traffic and post-traffic hooks, these functions can help to verify that the newly deployed code is configured correctly and your application works as expected. Also, it rollbacks the deployment automatically if something goes wrong.

PreTraffic hook is usually done before the traffic shifting starts. This function is a Lambda function that will be invoked by CodeDeploy. This lambda must return a callback to CodeDeploy with a success or failure. If the function fails, then the deployment is aborted and if it’s successful it will continue the deployment.

PostTraffic hook is similar to the PreTraffic hook, but it executes after the traffic shifting completes. This can be used to run integration tests.

In CodeDeploy there are many preconfigured deployment types:

• Canary10Percent30Minutes
• Canary10Percent5Minutes
• Canary10Percent10Minutes
• Linear10PercentEvery10Minutes
• Linear10PercentEvery1Minute
• Linear10PercentEvery2Minutes
• Linear10PercentEvery3Minutes
• AllAtOnce

You can choose your deployment strategy, and you can see it in action on the console.

Here is the link to the talk of Ben Kehoe in Serverless conf 2016: https://youtu.be/rsh6eKc1tVM