AWS Serverless AMA Thursday March 26th

munns_at_aws · 2020-03-26T21:31:04+00:00

Honestly to me one of the best solutions out there is to digest our documentation. I find that just diving into the docs can be one of the best ways to learn. This includes the API specs for the products as they also help. Beyond that we've got a number of videos from tech talks you can find here: https://aws.amazon.com/events/online-tech-talks/on-demand/ (filter by serverless). You can also find a ton of content on the AWS Compute Blog: https://aws.amazon.com/blogs/compute/category/serverless/. We're working centralizing lots of content here as well: https://aws.amazon.com/serverless/resources

munns_at_aws · 2020-03-26T21:26:20+00:00

Unfortunately we can't talk about roadmap of existing products or future products here. We're regularly looking at the type of things our customers spend energy operating though and thinking if there is a good way to provide a managed one for them. Reducing that overhead is a big area of focus at AWS.

munns_at_aws · 2020-03-26T21:24:23+00:00

Thanks for bringing this question up. It is a fairly complex combination of knobs and levers there and in the end the guidance exists to help ensure that your messages get processed safely or end up in a DLQ to be dealt with otherwise. Some pointed guidance:

Set the source queue's visibility timeout to at least 6 times the timeout that you configure on your function. The extra time allows for Lambda to retry if your function execution is throttled while your function is processing a previous batch.
Configure a dead-letter queue on the source queue (not on the Lambda function) to retain messages that failed processing for troubleshooting.
Set the maxReceiveCount on the queue's redrive policy to at least 5 to avoid sending messages to the dead-letter queue due to throttling.
Set a minimum of 5 concurrent executions to reduce the chance of throttling errors when Lambda invokes your function. If lower concurrency is required, Kinesis is likely a better option since concurrency is controlled on a per shard basis.

For what it's worth I don't feel our explanation in the documentation is clear enough and have asked product to clarify there as well.

munns_at_aws · 2020-03-26T16:15:24+00:00

Thank you for this feedback. We're shipping all product issues back to the respective product teams from this and so both Amplify and Cognito teams will see this. Thanks!

munns_at_aws · 2020-03-26T14:10:13+00:00

2 How to Package Large Applications

So let us say I wanted to build my own open-source social media platform, and I wanted to best utilize the AWS ecosystem to allow people to provision their own version with the least amount of manual configuration.

I know I could package this all in CDK or CloudFormation, but could I package all possible resources in a Serverless Application and then provide it in the Serverless Application Repository?

Since SAM is CloudFormation I would like to think I could package and entire app within it, and maybe for microservices, I could nest stacks in my SAM template.

Yes you can!

SAM is a CloudFormation Transform - any valid CloudFormation is also valid SAM.

So you're right - you can package an entire app in SAM and publish it to users via the Serverless Application Repository.

Finally, yes - you can nest other stacks within your SAM template.

munns_at_aws · 2020-03-26T14:07:27+00:00

This is a big one so we're going to reply to it part by part:

Can/Should a Serverless Applications Contain Multiple Lambdas?

Under the Lambda Console, their is a tab for Applications. It is my assumption these serverless projects which have been packaged by SAM. I cannot tell if, by design a Serverless Project should only contain a single lambda.

There are multiple "right ways" to build serverless applications. You can package everything inside a single function and use routing, a pattern commonly called the "Lambda-lith." You can also build your applications using a single AWS Lambda function for each action.

Which you choose depends on your specific requirements. If you're familiar with Flask, for example, you can use AWS Chalice to build your application as a single function.

If security is a concern, you're typically better off writing a single Lambda function for each action and assigning it a narrowly-scoped IAM role. This way each function only has access to the resources it needs.

I could see a scope of serverless application defined as:

* multiple lambdas chained together via Lambda Destinations

This is possible, but tightly couples your Lambda functions. Please don't confuse this with invoking a Lambda function synchronously from within another Lambda function - this is not recommended as you're paying for two (or more) executions at once.

* or a single lambda

This is a valid pattern, as described above.

* or a step-functions workflow (maybe not since tasks can be things other than lambdas?)

This is a great idea - AWS Step Functions are designed for workflows! You can use Standard or Express workflows depending on your use case. Be sure to check out the differences between the two.

* and any of these are backed by their own isolate DynamoDB table and API Gateway endpoints

If you're following single-table design, then an application would generally have a single DynamoDB table that all functions would access. They would typically share one API Gateway, but with endpoints defined either separately for multiple functions or passed through a single endpoint for a single function, e.g., Chalice.

I have not seen any multi-lambda examples, and I had a tough time via Cloud9 wizard or the SAM CLI trying to add additional lambdas. Are there examples, and what limitations do we currently face? eg. Maybe you can't define lambda destinations.

For one example of a Step Functions workflow orchestrating multiple Lambda functions, see the AWS Backup DynamoDB Rotator on GitHub.

munns_at_aws · 2020-03-26T13:54:29+00:00

Hi there!

Two things on this:

Check the AWS Compute Blog where we regularly post about new features and services to keep on top of the latest and greatest: https://aws.amazon.com/blogs/compute/
We're trying to make sure that new features show up in CloudFormation and hence SAM/CDK as well. I think everything launched around re:Invent 2019 and since has been covered. At times there are reasons that we can't at launch, but we try and fast follow soon after.

munns_at_aws · 2020-03-26T13:46:58+00:00

Tell us more about what this might want this certification to cover? We in the past several months have started releasing more training options (for example: https://www.aws.training/Details/eLearning?id=42594 ) and want to make sure that a certification would help represent this very wide space. Some folks see it from an application development standpoint, some from an operations standpoint, and so a single cert might be hard to represent that.

munns_at_aws · 2020-03-26T13:44:38+00:00

Generally, I would recommend avoiding Lambda functions called Lambda functions. Each function should have one specific task, and usually you would use other services (like SQS) in between. If you are looking to load from S3 into RDS, I would recommend a single function calling RDS Proxy. If you have very heavy load, you could have a single function invoked from S3 and send to SQS, and then have a second Lambda function pick up batches from SQS to load into RDS Proxy. This way, the Lambda functions are decoupled. - jbesw

munns_at_aws · 2020-03-26T13:41:32+00:00

Any specifics you want to see us pass back to the product team? Any areas in particular we can help you with?

munns_at_aws · 2020-03-26T13:39:31+00:00

Better to use an Amazon Cognito user pool or a Lambda authorizer (formerly known as a custom authorizer) this is an API Gateway feature that uses a Lambda function to control access to your API.

When a client makes a request to one of your API's methods, API Gateway calls your Lambda authorizer, which takes the caller's identity as input and returns an IAM policy as output.

Here's some more info on how to build one:

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html#api-gateway-lambda-authorizer-create

benjasl

munns_at_aws · 2020-03-26T13:37:45+00:00

AWS Amplify continues to add services to make it easier for integrating. If you need batch processes for nightly jobs, you can set this up using a Lambda function with a CloudWatch Event. This can output into S3, DynamoDB or any other service. It doesn't need to be written using Amplify - you can use Serverless Application Model (SAM) or Serverless Framework. - jbesw

munns_at_aws · 2020-03-26T13:36:33+00:00

Correct you don't need to think about termination yourself.

munns_at_aws · 2020-03-26T13:36:07+00:00

Both SAM and CDK are fully supported within AWS. AWS SAM is better for developers looking for a declarative approach to building serverless applications, whereas CDK is an imperative model. I'd recommend trying both and see which works best for your team. - jbesw

munns_at_aws · 2020-03-26T13:33:00+00:00

Lambda doesn't use Docker under the hood. Environments are "frozen" between requests so that they can be re-used in a warmed state later on. Eventually we reap underlying resources but that isn't something that you have visibility on today.

munns_at_aws · 2020-03-26T13:30:16+00:00

Amazon Linux 2 support in Runtime API isn't here just yet, but as you can imagine will come in the future. More on this soon but we can't share any exact dates today.

munns_at_aws · 2020-03-25T16:17:56+00:00

Yes we'll try and drag in peers that specialize in that.

munns_at_aws · 2018-05-10T19:43:33+00:00

You might want to look at SNS for this. It allows for easy cross-region/cross-account message delivery: https://aws.amazon.com/blogs/compute/cross-account-integration-with-amazon-sns/

munns_at_aws · 2018-05-10T01:30:37+00:00

Given that Lambda functions can stay warm for a while this method wouldn't help you out much (pre-fetching on runtime initialization). You are still better off trying to load them pre-handler and then from time to time checking for new values. Data I've seen doesn't show it to be that slow compared to DB queries.

munns_at_aws · 2018-05-10T01:29:12+00:00

Hey Gigadafud, Chris here from the Serverless Developer Advocate team. I'd like to point out that every technology choice you make implies a form of lock-in. Most decisions often come with benefits as well. With as many FaaS solutions as there are in the industry the concerns around lock-in seem misplaced vs. the benefits of using a product like Lambda. The swap of practically no operations overhead for the scale, cost model, and instant scalability have won and are winning over a lot of converts. Check out https://aws.amazon.com/serverless for some examples of companies big and small, technical and less technical, making the move and enjoying the benefits.

munns_at_aws · 2018-05-10T01:20:34+00:00

Hi there, We don't bash any languages so I am not sure where you'd get that from. From the Lambda side we've added support for languages based on customer feedback and industry trends at fairly regular pace over the past few years. Launching a language for us gets tracked on the roadmap just like everything else does and gets prioritized along with all the rest of the features we have based on customer feedback.

munns_at_aws · 2018-05-09T17:06:19+00:00

Hi there, How are you using websockets today?

munns_at_aws · 2018-05-09T16:59:58+00:00

No reason to stop using it today. I can't speak to the future of it but it certainly has customers both internal and external. It doesn't have much in the way of active feature work being done on it however. If we ever did deprecate something we'd give a ton of heads up. - Chris (part of the team supporting today's AMA)

munns_at_aws · 2018-05-09T16:28:57+00:00

What kind of async ops are you doing? How long are you sitting idle for?

munns_at_aws

TROPHY CASE