6 ms·

I've found Lambda to be really ridiculously fucking cheap. We moved image resizing onto it and saved thousands a month. Don't compare the cost of Lambda per 10

I've found Lambda to be really ridiculously fucking cheap. We moved image resizing onto it and saved thousands a month. Don't compare the cost of Lambda per 100ms to the cost of a virtual machine per month since Lambda only charges as you use it. You'd have to have the CPU pegged at 100% usage to make that a fair comparison. Mind you even if you took the cost of Lambda per 100ms and multiplied that out for a monthly cost it's still about the same as an EC2 instance of the same capacity. (Eg. if I had a 1GB Lambda running for a total of 1 month compute time in the uswest2 region it'd cost $32). Oh and the cost of API gateway is $3.50 per million requests and the bandwidth cost is completely negligible for us (we redirect to the resized image hosted on S3, fronted by cloudfront). We get 3 million image resizing requests a day. That's over 30 per second. It would take a lot of VMs to handle that (image resizing isn't trivial). Or we could just pay the whole $11.50. I have to ask have you done the math? Lambda beats everything in cost except for some funky solutions using unreliable and less scalable lowendbox.com services.

010a 10y ago
I would say that it strongly depends on the type of requests you are handling. Saying that you can run a 1GB lambda for 1 month nonstop for $32 does not impress me, and its kind of strange that it impresses you. You could run a t2.micro with the same RAM for $6/mo if you reserve it for a year. And if you want to give that t2.micro a workload where it only has to respond to 1 request at a time, the same terms we are affording the lambda system, then it's no comparison. Now, for responding to disparate requests every once in a while? Lambda is ideal. You can spin it up and you don't have to pay when it is isn't processing requests. But continuous requests? Hard no. We can argue that the cost overhead at full load is worth it for the ability to "infinitely" scale with no effort. Alright, that's fine. But let's not pretend that it is "cheaper".
- nathancahill 10y ago
  I don't have a strong opinion one way or the other, but I'd like to point out that micro instances also have diminished networking (besides processing/memory). Depending on what you're doing, this could be a factor.
  - 010a 10y ago
    We can afford a t2.medium or an m3.medium at the price he quoted, which will have better RAM, processing capability, and probably equivalent networking capability, so that isn't really the takeaway point.
    - pyrale 10y ago
      The point is, his lambda setup has vastly better capability than your instance, should he need it. Unless you're able to bring instances up fast enough to address your need, which clearly doesn't put you in the same ballpark as him.
- ralusek 10y ago
  You can't compare it to a t2.micro because that's not what you're getting with lambda. t2.micro is a single, weak piece of hardware meant to handle 30 requests per second? I forsee issues there. For the same traffic would be called in parallel when the spikes require it, which is something you would not get without scaling the t2 micro and programming concurrency. And that is ultimately where the comparison comes in. Because hardware needs to be able to accommodate unpredictable traffic, it is running all the time, and it is beefier than it needs to be. The performance buffer to account for unpredictable traffic is completely eradicated when using FaaS. I still use dedicated hardware where I deem it appropriate, but the proof is in the pudding. For the right services, pulling them out into lambdas is proving to be a huge savings and performance boost for countless architectures.
e12e 10y ago
Whenever I've looked half-seriously at any cloud offering, I've come to the conclusion that it's the data transfer/bandwidth that kills vis-a-vis dedicated services. If you don't need ~10TB/month, then sure - it doesn't really matter. If you do then you need to get a lot of reduced ops work for your effort. I suppose that if while testing/starting out you use little bandwidth, and any additional bandwidth/users comes with income - it doesn't really matter that a chunk of that goes to AWS, and not to your business. For those that actually do run non-trivial things on AWS (or other clouds) - do feel this is an accurate assessment? That bandwidth is still really expensive in the cloud?

010a 10y ago

I would say that it strongly depends on the type of requests you are handling. Saying that you can run a 1GB lambda for 1 month nonstop for $32 does not impress me, and its kind of strange that it impresses you. You could run a t2.micro with the same RAM for $6/mo if you reserve it for a year. And if you want to give that t2.micro a workload where it only has to respond to 1 request at a time, the same terms we are affording the lambda system, then it's no comparison. Now, for responding to disparate requests every once in a while? Lambda is ideal. You can spin it up and you don't have to pay when it is isn't processing requests. But continuous requests? Hard no. We can argue that the cost overhead at full load is worth it for the ability to "infinitely" scale with no effort. Alright, that's fine. But let's not pretend that it is "cheaper".

nathancahill 10y ago
I don't have a strong opinion one way or the other, but I'd like to point out that micro instances also have diminished networking (besides processing/memory). Depending on what you're doing, this could be a factor.
- 010a 10y ago
  We can afford a t2.medium or an m3.medium at the price he quoted, which will have better RAM, processing capability, and probably equivalent networking capability, so that isn't really the takeaway point.
  - pyrale 10y ago
    The point is, his lambda setup has vastly better capability than your instance, should he need it. Unless you're able to bring instances up fast enough to address your need, which clearly doesn't put you in the same ballpark as him.
ralusek 10y ago
You can't compare it to a t2.micro because that's not what you're getting with lambda. t2.micro is a single, weak piece of hardware meant to handle 30 requests per second? I forsee issues there. For the same traffic would be called in parallel when the spikes require it, which is something you would not get without scaling the t2 micro and programming concurrency. And that is ultimately where the comparison comes in. Because hardware needs to be able to accommodate unpredictable traffic, it is running all the time, and it is beefier than it needs to be. The performance buffer to account for unpredictable traffic is completely eradicated when using FaaS. I still use dedicated hardware where I deem it appropriate, but the proof is in the pudding. For the right services, pulling them out into lambdas is proving to be a huge savings and performance boost for countless architectures.

e12e 10y ago

Whenever I've looked half-seriously at any cloud offering, I've come to the conclusion that it's the data transfer/bandwidth that kills vis-a-vis dedicated services. If you don't need ~10TB/month, then sure - it doesn't really matter. If you do then you need to get a lot of reduced ops work for your effort. I suppose that if while testing/starting out you use little bandwidth, and any additional bandwidth/users comes with income - it doesn't really matter that a chunk of that goes to AWS, and not to your business. For those that actually do run non-trivial things on AWS (or other clouds) - do feel this is an accurate assessment? That bandwidth is still really expensive in the cloud?