3 ms·

I use Lambda heavily, especially in new projects that haven't been proven yet. The cost savings are significant for two reasons: - Easier to maintain so less h

by throwaway2016a 5y ago

I use Lambda heavily, especially in new projects that haven't been proven yet. The cost savings are significant for two reasons: - Easier to maintain so less hours spent handling things like deployment and autoscaling. Payroll is likely the company's top expense so this is not insignificant. - If the traffic is sporadic or unpredictable you have 100% efficient resource utilization, which is very difficult with traditional servers. I have some microservices that would cost $10 per AZ / datacenter per month (so at least three to have High Availability) that cost effectively $0 per month on lambda. At scale, it depends on how consistent your load is. If it is highly consistent a server may make sense. But even for high traffic apps the cost can be lower or -- if it is higher -- so negligibly higher that the saved maintenance cost pays for it. I have many projects on Lambda, but for example: I run an entire small-startup of mine for < $1 per month and have high availability. The number of hours I would need to spend to get the cost that low would be way too expensive.

paxys 5y ago
> If the traffic is sporadic or unpredictable you have 100% efficient resource utilization, which is very difficult with traditional servers. Kinda. Amazon is the one getting 100% efficient resource utilization (or close to it). You will be billed based on what's on their rate chart, not utilization.
htunnicliff 5y ago
Care to share more about your small startup?
- throwaway2016a 5y ago
  Well, I'd love to share specifics but I've kept "throwaway2016a" anonymous for 6 years so gonna keep it that way :). But some general info: - API based product - Frontend using Next.js hosted on S3 behind CloudFront with some CloudFront Edge functions - Gets a few hundred thousand API calls a month - I wrote my non-edge Lambdas in Go. I found it to be much faster cold start times (about 100ms for me) and much faster runtime (< 10ms) than Node. The Edge functions are Node though because Edge on AWS only supports the Node.js runtime. - I use DynamoDB for my database. You get billed for what you use on Lambda and on average a single API call bills me for 8 - 12ms each. Plus the cost of API gateway. Actual response time is higher since SSL negotiation and API Gateway adds overhead but it's usually < 80 - 100ms which is within my SLA. But could scale up to a few million API calls a month without much added cost... about 20 - 30 million API calls per month before I hit the cost of the (minimum) 3 servers + load balancer I would need to do High Availability using servers.
oblio 5y ago
> If it is highly consistent a server may make sense. I'd argue that you should just package and deploy your Lambda as a Docker image and when you need consistency head over to Fargate. It's costs are reasonably comparable with EC2 and you get rid of most Lambda limitations.
- throwaway2016a 5y ago
  Very good point that the Lambda code can be written in such a way that it can run from both Docker and Lambda. But I'm not a fan of Fargate. I find it easier to use vanilla EC2, and it's cheaper than Fargate. But I'm also very comfortable with EC2 and Fargate takes care of a lot of the ops stuff so to each their own. What I didn't mention too is Lambda has "Reserved Concurrency" pricing which for extremely consistent workloads lowers the gap... I've never had a product with that consistent a workload though.
cbsmith 5y ago
> If the traffic is sporadic or unpredictable you have 100% efficient resource utilization, which is very difficult with traditional servers. "100% efficient resource utilization" is a bit over stating it, but it sure is a lot easier to ensure you don't over provision.
- WatchDog 5y ago
  Also given that a lambda instance can only handle one request at a time, it generally gets very poor CPU utilization. Google cloud-run can handle multiple requests at a time, but still suspends the instance while no requests are being processed, and is billed to the nearest 100ms
  - throwaway2016a 5y ago
    Lambda is billed to the nearest 1ms and you can always lower your RAM and CPU requirements per function. Though at some point you hit the minimum. To flip (because I'm generally pro lambda) the one call per instance also encourages global state (since you don't need to worry about two calls running in parallel using the same memory), which is pretty bad coding practice.
    - iCarrot 5y ago
      A few years back at $DAY_JOB I was trying to optimize the cost for a serverless stack. To my surprise, small RAM lambda instances had extra latency of up to 100ms for DynamoDB queries!
      - throwaway2016a 5y ago
        Depends on if your workload is CPU or I/O bound. It's true that CPU and RAM and proportional in Lambda and raising or lowering the RAM also raises and lowers your CPU. I'm not sure why but I found with pre-compiled languages like Go it's not as big an issue (as long as your app is I/O bound). With Node.js I've found that increasing the size of the Lambda helps even with I/O bound functions. I assumed it was because the JIT compiling of the JS takes CPU but it also seems slower on subsequent runs and Lambda sleeps the apps it doesn't stop them (until you hit the end of the 5 minute reuse window). I give my Node.js a min of 1 Gig of RAM whereas I've been able to get some of my Go functions down to 128MB with no performance hit. Which yes, means the Node.js functions are about twice as expensive per MS before you even consider that the Go function runs for less time. But in both cases I've still found it cheaper than servers due to efficiency even though strictly speaking it costs more than a server per GB/Ghz.

paxys 5y ago

> If the traffic is sporadic or unpredictable you have 100% efficient resource utilization, which is very difficult with traditional servers. Kinda. Amazon is the one getting 100% efficient resource utilization (or close to it). You will be billed based on what's on their rate chart, not utilization.

htunnicliff 5y ago

Care to share more about your small startup?

throwaway2016a 5y ago
Well, I'd love to share specifics but I've kept "throwaway2016a" anonymous for 6 years so gonna keep it that way :). But some general info: - API based product - Frontend using Next.js hosted on S3 behind CloudFront with some CloudFront Edge functions - Gets a few hundred thousand API calls a month - I wrote my non-edge Lambdas in Go. I found it to be much faster cold start times (about 100ms for me) and much faster runtime (< 10ms) than Node. The Edge functions are Node though because Edge on AWS only supports the Node.js runtime. - I use DynamoDB for my database. You get billed for what you use on Lambda and on average a single API call bills me for 8 - 12ms each. Plus the cost of API gateway. Actual response time is higher since SSL negotiation and API Gateway adds overhead but it's usually < 80 - 100ms which is within my SLA. But could scale up to a few million API calls a month without much added cost... about 20 - 30 million API calls per month before I hit the cost of the (minimum) 3 servers + load balancer I would need to do High Availability using servers.

oblio 5y ago

> If it is highly consistent a server may make sense. I'd argue that you should just package and deploy your Lambda as a Docker image and when you need consistency head over to Fargate. It's costs are reasonably comparable with EC2 and you get rid of most Lambda limitations.

throwaway2016a 5y ago
Very good point that the Lambda code can be written in such a way that it can run from both Docker and Lambda. But I'm not a fan of Fargate. I find it easier to use vanilla EC2, and it's cheaper than Fargate. But I'm also very comfortable with EC2 and Fargate takes care of a lot of the ops stuff so to each their own. What I didn't mention too is Lambda has "Reserved Concurrency" pricing which for extremely consistent workloads lowers the gap... I've never had a product with that consistent a workload though.

cbsmith 5y ago

> If the traffic is sporadic or unpredictable you have 100% efficient resource utilization, which is very difficult with traditional servers. "100% efficient resource utilization" is a bit over stating it, but it sure is a lot easier to ensure you don't over provision.

WatchDog 5y ago
Also given that a lambda instance can only handle one request at a time, it generally gets very poor CPU utilization. Google cloud-run can handle multiple requests at a time, but still suspends the instance while no requests are being processed, and is billed to the nearest 100ms
- throwaway2016a 5y ago
  Lambda is billed to the nearest 1ms and you can always lower your RAM and CPU requirements per function. Though at some point you hit the minimum. To flip (because I'm generally pro lambda) the one call per instance also encourages global state (since you don't need to worry about two calls running in parallel using the same memory), which is pretty bad coding practice.
  - iCarrot 5y ago
    A few years back at $DAY_JOB I was trying to optimize the cost for a serverless stack. To my surprise, small RAM lambda instances had extra latency of up to 100ms for DynamoDB queries!
    - throwaway2016a 5y ago
      Depends on if your workload is CPU or I/O bound. It's true that CPU and RAM and proportional in Lambda and raising or lowering the RAM also raises and lowers your CPU. I'm not sure why but I found with pre-compiled languages like Go it's not as big an issue (as long as your app is I/O bound). With Node.js I've found that increasing the size of the Lambda helps even with I/O bound functions. I assumed it was because the JIT compiling of the JS takes CPU but it also seems slower on subsequent runs and Lambda sleeps the apps it doesn't stop them (until you hit the end of the 5 minute reuse window). I give my Node.js a min of 1 Gig of RAM whereas I've been able to get some of my Go functions down to 128MB with no performance hit. Which yes, means the Node.js functions are about twice as expensive per MS before you even consider that the Go function runs for less time. But in both cases I've still found it cheaper than servers due to efficiency even though strictly speaking it costs more than a server per GB/Ghz.