3 ms·

Hey all, My name is Chris Munns and I am currently the lead Developer Advocate for Serverless at AWS (I am part of the Lambda PM team). We really appreciate t

by munns 9y ago

Hey all, My name is Chris Munns and I am currently the lead Developer Advocate for Serverless at AWS (I am part of the Lambda PM team). We really appreciate this feedback and are always looking for ways to hear about these pain points. Can email me directly: munns@amazon.com if you ever get stuck. Thanks, - Chris

runamok 9y ago
I am on a devops team trying to implement lambda by splitting pieces off from a monolithic Java app where applicable. The biggest pain point I have is because we have multiple "environments" (such as dev, da, staging) in the same amazon account and because lambdas are global I can't limit access to resources via IAM easily without hacks. Aka, because the same lambda will be used (but different versions and/or aliases) on all environments I can't marry the code and configuration to limit access to say RDS or elasticache or an S3 bucket per lambda. I feel like I need a higher order primitive (a lambda group that is role + configuration can live in that includes the lambdas) to achieve this. I realize api gateway has the concepts of stages but currently the idea is for some lambdas to be invoked directly by the monolithic app or via SNS/SQS async. Otherwise I could namespace my lambda functions which is hacky and make DevFooBar, StageFooBar, etc. Currently we plan to split off our environments into separate AWS accounts.
- philliphaydon 9y ago
  To get around the IAM issue we deployed the lambda's with a naming convention like: prod_lambda_name staging_lambda_name dev_lambda_name Then the IAM's are written with resource access to prod_* staging_* etc. It allows to give full permissions to the developer to create dev ones, modify the other ones, but the prod_ are all controlled by a smaller group of people. It's a bit hacky but it works well enough. Would be nicer to grant access by stages.
- str3tch76 9y ago
  check out the Serverless Framework (www.serverless.com) This will take all this pain awawy from you. It makes it very easy to push to different stages (dev, uat, prod etc)
- munns 9y ago
  Hi Runamok, Today given that aliases/versions do not have any sort of different permissions you are probably best to either run completely different stacks of resources or the multiple account model. With AWS Organizations these days its not that hard to run multiple environments across accounts. We did a webinar on some of this a few months back, the slides here might be useful to you: https://www.slideshare.net/AmazonWebServices/building-a-development-workflow-for-serverless-applications-march-2017-aws-online-tech-talks https://www.slideshare.net/AmazonWebServices/building-a-deve... It heavily leverages AWS's tools, but you could create similar practices using 3rd party frameworks and CI/CD tools as well. Thanks, -munns
- GordonS 9y ago
  I know we're discussing AWS here, but I find Azure handles this nicely. It has a 'slots' concept, so you can have a slot for production, another for QA, and any more you need. The really great thing is the ability to swap slots - so once you've finished testing a new QA build, you swap the QA and production slots, so what was running in QA is now running in production.

by munns 9y ago

runamok 9y ago

I am on a devops team trying to implement lambda by splitting pieces off from a monolithic Java app where applicable. The biggest pain point I have is because we have multiple "environments" (such as dev, da, staging) in the same amazon account and because lambdas are global I can't limit access to resources via IAM easily without hacks. Aka, because the same lambda will be used (but different versions and/or aliases) on all environments I can't marry the code and configuration to limit access to say RDS or elasticache or an S3 bucket per lambda. I feel like I need a higher order primitive (a lambda group that is role + configuration can live in that includes the lambdas) to achieve this. I realize api gateway has the concepts of stages but currently the idea is for some lambdas to be invoked directly by the monolithic app or via SNS/SQS async. Otherwise I could namespace my lambda functions which is hacky and make DevFooBar, StageFooBar, etc. Currently we plan to split off our environments into separate AWS accounts.

philliphaydon 9y ago
To get around the IAM issue we deployed the lambda's with a naming convention like: prod_lambda_name staging_lambda_name dev_lambda_name Then the IAM's are written with resource access to prod_* staging_* etc. It allows to give full permissions to the developer to create dev ones, modify the other ones, but the prod_ are all controlled by a smaller group of people. It's a bit hacky but it works well enough. Would be nicer to grant access by stages.
str3tch76 9y ago
check out the Serverless Framework (www.serverless.com) This will take all this pain awawy from you. It makes it very easy to push to different stages (dev, uat, prod etc)
munns 9y ago
Hi Runamok, Today given that aliases/versions do not have any sort of different permissions you are probably best to either run completely different stacks of resources or the multiple account model. With AWS Organizations these days its not that hard to run multiple environments across accounts. We did a webinar on some of this a few months back, the slides here might be useful to you: https://www.slideshare.net/AmazonWebServices/building-a-development-workflow-for-serverless-applications-march-2017-aws-online-tech-talks https://www.slideshare.net/AmazonWebServices/building-a-deve... It heavily leverages AWS's tools, but you could create similar practices using 3rd party frameworks and CI/CD tools as well. Thanks, -munns
GordonS 9y ago
I know we're discussing AWS here, but I find Azure handles this nicely. It has a 'slots' concept, so you can have a slot for production, another for QA, and any more you need. The really great thing is the ability to swap slots - so once you've finished testing a new QA build, you swap the QA and production slots, so what was running in QA is now running in production.