5 ms·

I worked on a project where the architect wanted to use Lambdas for the entire solution. This was a bad choice. Lambdas have a lot of benefits - for occasiona

I worked on a project where the architect wanted to use Lambdas for the entire solution. This was a bad choice. Lambdas have a lot of benefits - for occasional tasks they are essentially free, the simple programming model makes them easy to understand in teams, you get Amazon's scaling and there's decent integration with caching and logging. However, especially since I had to use them for whole solution, I ran into a ton of limitations. Since they are so simple, you have to pull in a lot of dependencies which negate a lot of the ease of understanding I mentioned before. The dependencies are things like Amazon's API Gateway, AWS Step Functions, and AWS CLI itself, which is pretty low-level. So now, the application logic is pretty easy, but now you are dealing with a lot of integration devops. There's API Gateway is pretty clunky and surprisingly slow. Lambdas shut themselves down, and restarting is slow. The Step Functions have a relatively small payload limit that needs to be worked around. Etc. So use them sparingly!

Prefinem 9y ago
1. Use a framework for deploying your lambda functions. There are a few that will manage the API Gateway for you. 2. Don't put the Lambda inside a VPC if you want lower response times 3. Step Functions don't seem ready for prime time that I can tell. (This might have changed in the last couple of months) 4. Lambda Functions should be microservices. Small and lean. 5. There is a limit on resources for CloudFormation so at about 20-30 functions with API Gateway on the serverless framework, you will hit a limit and can't add anymore (other deployment tools which don't use CloudFormation shouldn't have an issue) 6. Want more CPU, add more RAM
- philliphaydon 9y ago
  Don't put the Lambda inside a VPC if you want lower response times Response time's are fine inside a VPC... People keep saying gateway is slow but it isn't from my experience...
  - Prefinem 9y ago
    API Gateway adds around 200ms to each call for us based on our testing plus another 100ms if it’s inside a VPC. What region are you in? Our VPC has a NAT Gateway so that our Lambda functions can talk to the internet as well. I am by no means an expert and am reporting what watching the time differences between Lambda reporting and our network calls shows. Edit: this is by no means a deal breaker or anything. Just something that shocked me when I first noticed it.
    - philliphaydon 9y ago
      (crap I just typed stuff out and pressed F5...) I haven't tried with a NAT Gateway. This is what I know. If the response is small, the request duration is small. Cloudfront > Gateway > Lambda > RDS (PostgreSQL) Response: 1k | 20ms-60ms 10k | 50ms-90ms 100k | 150ms-200ms 350k | 200ms-450ms That's a rough gauge of what I've experienced. I think the throughput on the gateway is the bottleneck.
      - Prefinem 9y ago
        Just hit one of our test endpoints Test #1 Lambda run time (140 ms) Total waiting time (354ms) Total time (358ms) Test #2 Lambda run time (300 ms) Total waiting time (490ms) Total time (567ms) Test #3 Lambda run time (139 ms) Total waiting time (479ms) Total time (485ms) This is for a 20kb payload single request. Stack: Custom Domain -> Cloudfront -> API Gateway -> VPC -> Lambda -> NAT Gateway -> ElasticSearch
        digitalsanctum 9y ago
        I'm curious why you have a NAT gateway between your Lambda and Elasticsearch?
        Prefinem 9y ago
        Lambda is inside the VPC which means it can’t connect to the outside world without a NAT Gateway.
- striglia 9y ago
  What makes you say Step Functions isn't ready for prime time? We've been using it (and SWF which it is based off) for about a year at decent scale and been generally very happy with it.
  - Prefinem 9y ago
    When I initially set the up, there was no way to edit or delete them. I haven't messed with them since, although, I did just check and there aren't any step functions in my account so it looks like they deleted the old ones. It may be time to test them out again, I just go bit pretty bad with the last time I implemented them and lost about a weeks worth of work because of it being un-usable.

Prefinem 9y ago

1. Use a framework for deploying your lambda functions. There are a few that will manage the API Gateway for you. 2. Don't put the Lambda inside a VPC if you want lower response times 3. Step Functions don't seem ready for prime time that I can tell. (This might have changed in the last couple of months) 4. Lambda Functions should be microservices. Small and lean. 5. There is a limit on resources for CloudFormation so at about 20-30 functions with API Gateway on the serverless framework, you will hit a limit and can't add anymore (other deployment tools which don't use CloudFormation shouldn't have an issue) 6. Want more CPU, add more RAM

philliphaydon 9y ago
Don't put the Lambda inside a VPC if you want lower response times Response time's are fine inside a VPC... People keep saying gateway is slow but it isn't from my experience...
- Prefinem 9y ago
  API Gateway adds around 200ms to each call for us based on our testing plus another 100ms if it’s inside a VPC. What region are you in? Our VPC has a NAT Gateway so that our Lambda functions can talk to the internet as well. I am by no means an expert and am reporting what watching the time differences between Lambda reporting and our network calls shows. Edit: this is by no means a deal breaker or anything. Just something that shocked me when I first noticed it.
  - philliphaydon 9y ago
    (crap I just typed stuff out and pressed F5...) I haven't tried with a NAT Gateway. This is what I know. If the response is small, the request duration is small. Cloudfront > Gateway > Lambda > RDS (PostgreSQL) Response: 1k | 20ms-60ms 10k | 50ms-90ms 100k | 150ms-200ms 350k | 200ms-450ms That's a rough gauge of what I've experienced. I think the throughput on the gateway is the bottleneck.
    - Prefinem 9y ago
      Just hit one of our test endpoints Test #1 Lambda run time (140 ms) Total waiting time (354ms) Total time (358ms) Test #2 Lambda run time (300 ms) Total waiting time (490ms) Total time (567ms) Test #3 Lambda run time (139 ms) Total waiting time (479ms) Total time (485ms) This is for a 20kb payload single request. Stack: Custom Domain -> Cloudfront -> API Gateway -> VPC -> Lambda -> NAT Gateway -> ElasticSearch
      - digitalsanctum 9y ago
        I'm curious why you have a NAT gateway between your Lambda and Elasticsearch?
        Prefinem 9y ago
        Lambda is inside the VPC which means it can’t connect to the outside world without a NAT Gateway.
striglia 9y ago
What makes you say Step Functions isn't ready for prime time? We've been using it (and SWF which it is based off) for about a year at decent scale and been generally very happy with it.
- Prefinem 9y ago
  When I initially set the up, there was no way to edit or delete them. I haven't messed with them since, although, I did just check and there aren't any step functions in my account so it looks like they deleted the old ones. It may be time to test them out again, I just go bit pretty bad with the last time I implemented them and lost about a weeks worth of work because of it being un-usable.