AWS Lambda – Some Important Changes I’d Like To See
16 May 2016Serverless Architectures: Monoliths, Nanoservices, Microservices & Hybrids
20 Jun 2016One thing that I have always been keen to get from AWS Lambda is configurable environment variables that can be set for each individual Lambda function. One thing I loved about the Serverless framework is that it supports a notion of environment variables, stored in a hidden ‘_meta’ folder and substituted in when the functions are deployed to Lambda.
On our serverless-hipchat-connect
project, we added persistence using DynamoDB, a serverless NoSQL database. To create this database, we added it to the `s-resources-cf.json`, such that the required tables would be created as part of a stage’s initialization.
The cool feature in this is that the Serverless Framework can capture the outputs of a CloudFormation template as environment variables for Lambda functions!
"DynamoDBAccessTokenTable": { "Type": "AWS::DynamoDB::Table", "DependsOn": "DynamoDBInstallationTable", "Properties": { "AttributeDefinitions": [ { "AttributeName": "oauthId", "AttributeType": "S" } ], "KeySchema": [ { "AttributeName": "oauthId", "KeyType": "HASH" } ], "ProvisionedThroughput": { "ReadCapacityUnits": 3, "WriteCapacityUnits": 1 } } } }, "Outputs": { "AccessTokenTableName": { "Description": "Name of the AccessTokenTable created by CloudFormation", "Value": { "Ref": "DynamoDBAccessTokenTable" } } }
This can then be referenced in a CloudFormation template’s configuration file:
"environment": { "SERVERLESS_PROJECT": "${project}", "SERVERLESS_STAGE": "${stage}", "SERVERLESS_REGION": "${region}", "ACCESS_TOKEN_TABLE": "${accessTokenTableName}" },
At GorillaStack, we like to give a bit back to the community. If you like what you see here you should check out the rest of our Open Source DevOps contributions.