3 ms·

To do a release, create a new serverless function with the new code. Initially, no traffic routes to it, all traffic goes to the old function. Change things so

by twic 7y ago

To do a release, create a new serverless function with the new code. Initially, no traffic routes to it, all traffic goes to the old function. Change things so 1% of traffic goes to the new function, and see if it looks okay. If it does, make that 2%, then 3%, or 4%, or 10%, etc. Once it's 100%, delete the old serverless function. The provider hosting your serverless functions might not give you that much control over routing. In that case, you would need to write another serverless function which sits in front of your serverless functions and does the routing. If you ever need to update that, well, then you have to cross your fingers.

wging 7y ago
> Once it's 100%, delete the old serverless function. I suggest keeping it around for a while. A function not being used should have cost equivalent to a database entry, not a running container or VM, so this should be cheap and the benefits are large. It's still possible to discover you need to roll back a change, even after you've been at 100% for a while. (And no, 'roll forward' is not a sufficient option, especially if that requires coding up a fix you may not even understand yet.)
primitivesuave 7y ago
This seems like a great strategy, thank you for your input! It can indeed be accomplished by AWS Global Accelerator along with application load balancers targeting Lambda functions to route a percentage of traffic. I am not sure about the overhead of having a Lambda function to route requests, I’ll have to look into the latency that adds (especially for cold starts).
- ultrafez 7y ago
  Using a lambda to route requests to other lambdas would result in you effectively doubling your Lambda cost, as your routing lambda would sit idling while waiting for the target lambda to return a result. If you're using API Gateway, it has a canary deployment option which can route percentages of customer traffic to different Stages, which gives you the gradual rollout capability that you wanted.

by twic 7y ago

wging 7y ago

> Once it's 100%, delete the old serverless function. I suggest keeping it around for a while. A function not being used should have cost equivalent to a database entry, not a running container or VM, so this should be cheap and the benefits are large. It's still possible to discover you need to roll back a change, even after you've been at 100% for a while. (And no, 'roll forward' is not a sufficient option, especially if that requires coding up a fix you may not even understand yet.)

primitivesuave 7y ago

This seems like a great strategy, thank you for your input! It can indeed be accomplished by AWS Global Accelerator along with application load balancers targeting Lambda functions to route a percentage of traffic. I am not sure about the overhead of having a Lambda function to route requests, I’ll have to look into the latency that adds (especially for cold starts).

ultrafez 7y ago
Using a lambda to route requests to other lambdas would result in you effectively doubling your Lambda cost, as your routing lambda would sit idling while waiting for the target lambda to return a result. If you're using API Gateway, it has a canary deployment option which can route percentages of customer traffic to different Stages, which gives you the gradual rollout capability that you wanted.