Miserlou / Zappa

Serverless Python
https://blog.zappa.io/
MIT License
11.89k stars 1.2k forks source link

Canary patterns in Zappa #1111

Open jleclanche opened 7 years ago

jleclanche commented 7 years ago

I'm currently playing with Zappa on a new project to see if I can switch to it on a custom-managed lambda project. One thing I'm confused about is the Zappa stages. It looks like stages are actually separate lambdas, rather than using native functionality; is that correct?

This is confusing for the following reason: AWS Lambda supports qualifier-based stages. Example: image

In our custom system, we created two API Gateway stages: production and canary. The production stage is our usual stage, which points to the production lambda alias. The canary stage always points to the canary alias.

When we roll out a new version, we first deploy it to canary, which then ingests a small percentage of our lambdas (which could be from 0% to n% increasing slowly over time or w/e). We check for errors happening in the canary lambda; if we find more errors than we should, we revert canary back to the old version. Otherwise, we consider the version ready to deploy and we change the production alias to be the latest version.

Can something like this be implemented in Zappa? Given the native zappa commands for deploys, rollbacks etc it seems easy at first but if it's using custom logic to implement what AWS natively offers, it might be trickier than I initially thought.

danielwhatmuff commented 6 years ago

@jleclanche implementing canary release functionality within zappa could be a lot easier now API gateway has released this - http://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html

ricardogsilva commented 5 years ago

I'm working with dev and prod aliases too and have a related use case:

Currently there are two (ugly) options for making this work:

jneves commented 5 years ago

Check the extends option, you can define the base stage and then extend from it.