Comment by djhworld | Hacker News Reader

Comment by djhworld | Hacker News Reader

The environment variables thing was desperately needed, I raised this as a Feature Request with AWS over a year ago (my work has enterprise support)

I remember them telling us a way to make a lambda function distinguish whether it is in a DEV/TEST or PROD environment was to do some sort of regex on the function name, which was suboptimal, especially if you have Lambda's created via CloudFormation.

We "got around" this problem by creating tables in DynamoDB as our DEV/PROD environments are in separate AWS accounts, so the dynamo tables contained simple key/value pairs that you would read once when the lambda container started up. Another option would be to have a file in S3 or something, but you still have to write code to manage the retrieval of those resources.

Looking forward to dropping all that infrastructure and using this feature instead.

Did you happen to raise a feature request for Python 3 as well? With any luck, we'll get that before Python 4 is released... :)

We primarily use Java 8, but I'd imagine a lot of people have raised it

Why aren't you using aliases[1] for denoting dev, prod, etc?

[1] http://docs.aws.amazon.com/lambda/latest/dg/versioning-alias...

This was before AWS introduced aliases and versioning, think back to summer 2015.

Aliases are still a half solution to this problem though, you would still need logic in your code to say "if alias == PROD then ... else ..." for configuration, something I'd rather do without.

EDIT: by configuration I mean configuration that's specific to an environment. Imagine you had a Lambda that wrote data to an S3 bucket, you wouldn't want to accidentally mix TEST/LIVE data in the same location, so you would use a configuration property to inform the Lambda where to write.

Thanks for the explanation, that makes sense. We wanted to see aliases as well, because it's cumbersome setting a client ID for our Lambda monitoring service.

Reply on news.ycombinator.com