3 ms·

Details on this would be great. We do a lot of serverless for content publishing and 3rd party api integration work... I’d love to hear more of how others use i

Details on this would be great. We do a lot of serverless for content publishing and 3rd party api integration work... I’d love to hear more of how others use it at scale. I can confirm a couple things. It seems like we spend a bit more time getting things to work as expected. Troubleshooting can get expensive given the system disappears. Telemetry on the lambdas needs to improve. Finding what’s eating time gets tough when you are looking to optimize. (A lot baked in to this statement but getting 800ms of compute to 400ms is sometimes important whilst staying on lambda)

mooreds 9y ago
Have you evaluated x-ray for performance tuning? http://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.html http://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.htm...
leetbulb 9y ago
Unfortunately I cannot provice much detail about the nature of the application, however I can say that we collect and process various types of events and perform automated actions based on them. The ingress begins at API Gateway, runs through a pipeline of Lambda functions, ends up in a Kinesis firehose, and ultimately in S3 for further processing. The primary cost (~60%) comes from API Gateway acting as the event ingress point, which was a design mistake...though at the time it did make things easier. We're currently working on migrating the event collectors to a pure CloudFront based solution (inspired by SnowPlow) where the events will be submitted to CloudFront via signed GET requests and the CF logs will be streamed to the same Lambda-based processing pipeline. Doing this will eliminate almost all of the overhead of API Gateway (still required for certain events that cannot be collected via HTTP GET).