What's the best practice for having different environments for lambda functions, i.e. dev/prod
Should I just have two lambda functions one called myFunction-prod and myFunction-dev or is there a better way to create environments.
I saw that Amazon API Gateway has a notion of "Stages" which accommodates separation of dev, staging and production versions of code.
Is there a similar notion with Amazon Lambda?
During re:Invent 2015 (Oct); versioning and aliases has been added to lambda; this official doc describes very well how to use this for prod and dev.
p.s. In order to test on the live data (w/o affecting the prod); I use SNS fan-out pattern (subscribing both prod and dev lambda's to the same SNS topic).
You can use AWS Gateway API. Once you created the lamdba functions, create a gateway which points to your lambda function. This can be done easily selecting using a dropdown.
As you mentioned, you can create 2 stages(live and staging) and map the appropriate gateway URLs to the stages. Then by selecting the appropriate method in stages, you can get the REST URL to access the stage.
For example, someurl/live and someurl/staging.
Also, while deploying the lamda function changes, choose the appropriate stage to deploy and test it out using the staging URL. Once its done, deploy the function to your live stage.
Just to add to Neil's you can also use Stage Variables to link to the respective Lambda Alias i.e. the dev stage will use the DEV alias of your lambda function while the prod stage will use the PROD alias of your lambda function. More about stage variables here Working with Stage Variables in Amazon API Gateway
One way to achieve this is by specifying a function input which tells the lambda function which environment to run the function in. Your lambda function should have the appropriate environment specific config.
If you have hooked up an API gateway to the lambda function, You might as well want to pass a header in your api requests to identify which environment you are targetting. However this is not an ideal solution, there would be better ways to do this.
AWS Console - lamdba does not provide this feature, it simply lists down all functions you have with their details.
Like you said You will need functions by environments and then manage the code movements between environment via a Build Integration server like jenkins or bamboo. Your deployment scripts internally will call aws sdk apis which will replace the function code in the target environment. For example UpdateFunctionCode
You can also make use of IAM Roles/policies to control deployment access.
I would recommend developing your own custom dashboard with your workflow OR integrate this into your existing devops tools. AWS console is not designed for production usage, you will need a dashboard to manage this eventually.
