3 ms·

$480 to process 66 request per second.. lol Even the smallest fargate task @ .25 CPU & 256mb of memory can do double that no problem, and for only like $30 WIT

$480 to process 66 request per second.. lol Even the smallest fargate task @ .25 CPU & 256mb of memory can do double that no problem, and for only like $30 WITH a load balancer. You get all the benefits of lambda, you keep your existing tooling, and you don’t have to deal with those icky “servers”. You also conveniently left out the price of API Gateway for the lambda costs, so add another $130. Unless of course you want to use function URLs and get hit with a Denial Of Wallet attack and bankrupt your entire company. Lambdas, for APIs, are good for one thing only: apps that don’t get traffic and have no business value. I would always use lambda for things like reading from SQS or processing S3 events- it just doesn’t make economical sense for a business critical API despite what all the marketing hype will tell you

cebert 4y ago
I am working on a project that uses Lambdas for all our APIs. Our costs are relatively low. Our app will never be FAANG scale; We serve a small market. The organization I am in is relatively new to the cloud and distributed systems. The largest befit of going serverless to me is that AWS does a lot of the heavy lifting, allowing my team focus on understanding our customer’s business needs. We can focus on getting that right instead of spending more on operations and complexity. We’re in three availability zones by default. DynamoDB has been demonstratively proven to scale. With slightly more investment multi-region failovers are easy to achieve. Our team has minimal production outages, which is amazing because we are not cloud experts and are learning as we build out our application.
- josevalerio 4y ago
  Have you run into any quirks while developing? I did, this one was especially annoying: https://github.com/serverless/serverless/issues/3785 https://github.com/serverless/serverless/issues/3785 Some other quirks: - 29 second timeout on API Gateway despite lambdas being able to run for 15 min - Middleware not being straight forward like in (name your framework, I'll mention Express), even with packages like Middy - Having to dig through the different log groups since a new one is created each time there's a new container that gets started
  - cebert 4y ago
    On my project we haven't because our lambdas run very quickly (we're basically a glorified CRUD app), but I have heard of this being an issue for others.

cebert 4y ago

I am working on a project that uses Lambdas for all our APIs. Our costs are relatively low. Our app will never be FAANG scale; We serve a small market. The organization I am in is relatively new to the cloud and distributed systems. The largest befit of going serverless to me is that AWS does a lot of the heavy lifting, allowing my team focus on understanding our customer’s business needs. We can focus on getting that right instead of spending more on operations and complexity. We’re in three availability zones by default. DynamoDB has been demonstratively proven to scale. With slightly more investment multi-region failovers are easy to achieve. Our team has minimal production outages, which is amazing because we are not cloud experts and are learning as we build out our application.

josevalerio 4y ago
Have you run into any quirks while developing? I did, this one was especially annoying: https://github.com/serverless/serverless/issues/3785 https://github.com/serverless/serverless/issues/3785 Some other quirks: - 29 second timeout on API Gateway despite lambdas being able to run for 15 min - Middleware not being straight forward like in (name your framework, I'll mention Express), even with packages like Middy - Having to dig through the different log groups since a new one is created each time there's a new container that gets started
- cebert 4y ago
  On my project we haven't because our lambdas run very quickly (we're basically a glorified CRUD app), but I have heard of this being an issue for others.