5 ms·

Is AWS lambda really cost effective? It has been many years since I was part of a team that was assessing AWS Lambda as _workers_ but the resource limitations a

by atmosx 5y ago

Is AWS lambda really cost effective? It has been many years since I was part of a team that was assessing AWS Lambda as _workers_ but the resource limitations at the time alongside cost calculation made PHP+VMs the cost-effective choice by orders of magnitude.

ep103 5y ago
Its loved because it means your technical costs are always guaranteed to be a % of your total computing needs, and your computing needs should (theoretically) always be proportional to your total company revenue. From a business standpoint, that's a pretty great pitch. Is it actually the most cost effective solution? No more so than any other tool. It depends on exactly what you're building, how, and how you measure the cost. AWS can be extremely costly, or cheap, depending on your engineering needs, constraints, and practices.
- deleted 5y ago
  [deleted]
- timr 5y ago
  I have been at exactly one (web) company in my life where the cost of computing resources actually mattered, and compared to bandwidth, even that didn't matter. The companies I have been at where computing costs did matter were doing extremely specialized, long-running calculations that are inappropriate for lambda. I'm sure there are rare exceptions, but this all smells like premature optimization. Developer salaries are, 9.99 times out of ten, the cost you want to optimize.
- sam0x17 5y ago
  Another area that this workflow really empowers is it frees you up to have infinite and arbitrary staging environments. In our case we have a GitHub action set up that creates a fully deployed version of the app for every PR automatically, and a bot that comments on the PR with a link to the deployment. You can of course do this with any kind of infrastructure, but only with a serverless sort of architecture is it virtually free to do this kind of thing. On the db side, we allocate extremely tiny instances so it is still quite affordable to just have one running for all of our branches. They are automatically destroyed when the PR is closed so the overhead is basically $5/month for each PR that is open for a whole month (in practice they are open for a few days at most).
  - atmosx 5y ago
    This is an interesting use case, thanks for sharing although these days, setting up kubernetes environment emulators is supported by most CI systems out of the box.
freeqaz 5y ago
They bill by the millisecond for usage now, which has helped bring down the cost a ton (at least for web services). And if you don't need fancy stuff, they have a cheaper version of API Gateway now too. Lambda also supports Docker and is pretty damn fast now, so it's less painful to use.
- sam0x17 5y ago
  Most seed stage startups don't even surpass the free tier in my experience, and depending on the product this can be true for a lot of Series A startups as well.
garethmcc 5y ago
I have worked with many teams and found lambda to be by far more cost effective. Did your calculations include the time lost waiting to deploy solutions while infrastructure gets spun up, the payment for staff or developers spending time putting infrastructure together instead of building solutions, the time spent maintaining the infrastructure, the cost of running servers at 2am when there is no traffic. Perhaps even the cost of running a fat relational database scaled for peak load that needs to bill you by the hour, again even when there is no traffic. Serverless as an architectural pattern is about more than just Lambda and tends to incorporate a multitude of managed services to remove the cost of managment and configuration overhead. When you use IaC tools like Serverless Framework that are built to help developers put together an application as opposed to provisioning resources, it means you can get things up fast and ready to bill you only for usage and that scales amazingly.
- daanlo 5y ago
  Funnily enough, I have made almost the opposite experience. In my experience IAC and serverless bring all the troubles of dev ops to „regular“ developers. Your plain vanilla mid-level full stack dev now needs to understand not only a bunch about FE & BE code, but also a much bigger bunch about servers, networking, VPCs, etc. than in a non-serverless setup. How do you resolve this in your projects? (Serious question). This is such a big problem for some of the projects that they are now only able to hire senior develops (which brings it‘s own set of problems).
  - emteycz 5y ago
    Deploying a Lambda function with Terraform or Pulumi seems to not require knowledge about servers or networking to me
  - sam0x17 5y ago
    Yeah, framework-ification of this process has been the real differentiator in the last 5 years that has taken lambda from being obtuse and glitchy to work with to quite a joy if you just lean on your framework. All of that said, I vastly prefer google cloud functions personally and would switch to that in a heartbeat if they had capabilities like API gateway but it's not there yet. I also regret that there isn't a better cross-cloud solution currently, but that's something I have a lot of open source ambitions about creating soon. I don't like serverless that much so stay tuned for something from me in the coming years, probably in Rust.
vorticalbox 5y ago
My biggest issue with lambda are these two limitations. 1. You have a maximum of 30 seconds to reply to the request 2. You cannot stream data from lambda through the api gateway. Though you can stream to s3 etc.
- sam0x17 5y ago
  Max limit is 15 minutes now. I agree streaming needs work, but if I had to deal with that I'd probably just use naked endpoints.
  - vorticalbox 5y ago
    Not when triggered by the api gateway, that is still 30 seconds for things triggered from sqs, s3 etc its 15 minutes.
    - sam0x17 5y ago
      Needing anything more than a few seconds out of API gateway is just bad application design though unless we're talking about websockets or streaming as you said. If it's a webhook, you risk the client hanging up if you do all that work up front (you should instead be scheduling a background lambda that will do it based on the webhook params). If it's an actual user, I'm assuming you're not expecting to have a user wait 30+ seconds for a page to load, so probably some JSON API endpoint with a progress bar on the frontend. In those cases there's really no need to use API gateway as it isn't visible to the user anyway (you could just use your lambda naked in that case). If you're talking about web sockets, yeah, I feel ya. I haven't had to navigate that situation yet but my plan of action is to bypass API gateway entirely and use a naked lambda running at its full execution time, and when we approach the 15 minute boundary, send a command that resets the connection. Don't know if it would work well but I haven't had a need to use web sockets for any projects I work on for a while. For streaming, like you said, maybe an elastic beanstalk cluster is more the way to go depending on your workflow. If you can find a way to get it all to work in Lambda though, would probably be a game changer cost-wise I would expect as long as you figure out a way to deal with resetting every 15 mins.
sam0x17 5y ago
With a spikey workload, it's almost always worth it because we have to scale up 1000x and then 10 mins later scale back down to 1x for the rest of the day, and this can happen any time of day randomly. You can also do this with load balancers but in practice I've found these to be much slower to scale and much more costly with the same workload. For reference, 90% of our bill is database related currently.
- exikyut 5y ago
  > 90% of our bill is database related currently. Huh. With the context of the rest of the comment, I realize (the very obvious comparison) that a database engine designed to shard to many thousands of small workers could potentially be a very attractive future development path. Iff the current trends in cloud computing (workers, lambda, etc) continues and some other fundamental doesn't come along and overtake. Which is probably (part of) the reason why this doesn't exist, since I think I've basically just described the P=NP of storage engineering :)
  - sam0x17 5y ago
    > Huh. With the context of the rest of the comment, I realize (the very obvious comparison) that a database engine designed to shard to many thousands of small workers could potentially be a very attractive future development path. Yes. I've been patiently waiting for the database community to realize this for the last 5 years now :)
    - exikyut 5y ago
      I have no delusions I'd be able to viably make a dent in the area (at least anytime soon), but I do wonder how this would actually work. The optimal solution would of course be to shard both the compute I/O and the storage footprint, so each worker only needed to hold onto maybe 1-100MB of data. Perhaps some existing (simpler) designs could be modified to "hyper-shard" the compute angle, but would still likely require carrying around a large percentage of the database. In any case, you'd need an internal signalling fabric capable of (cost-effectively) handling very bursty many-to-many I/O across thousands of endpoints to make consensus work in realtime. It would honestly be really interesting to see how something like this would work in practice.
jokethrowaway 5y ago
I'd say it's still the case for the majority of the cases. Which is a shame, because I like this idea of having hw limits for your software and being able to efficiently maximise hardware at the datacenter level for redundant, trivial applications (like serving web requests). Most web servers are half idle "just in case" because hardware is cheap and engineers time is expensive. I migrated some mid business (500-1000 people company) lambda setup to ec2 spot instances and a standard app and the costs dropped. It would have been even cheaper on something like heztner, but good luck getting a buy-in from the infra team. I venture most small businesses will have less load than them. Certainly it's not worth it for my tiny side businesses. I was running some calculations for a project though, and if you "abuse" them with lengthy / expensive calculations run very infrequently (think like a cron job), you may end up being quite cost effective.
PetahNZ 5y ago
We trialed switching over to lambda for our worker queues just last month. We went for $500 a month EC2 costs (auto scaling spot fleet), to $500 a day.

by atmosx 5y ago

ep103 5y ago

Its loved because it means your technical costs are always guaranteed to be a % of your total computing needs, and your computing needs should (theoretically) always be proportional to your total company revenue. From a business standpoint, that's a pretty great pitch. Is it actually the most cost effective solution? No more so than any other tool. It depends on exactly what you're building, how, and how you measure the cost. AWS can be extremely costly, or cheap, depending on your engineering needs, constraints, and practices.

deleted 5y ago
[deleted]
timr 5y ago
I have been at exactly one (web) company in my life where the cost of computing resources actually mattered, and compared to bandwidth, even that didn't matter. The companies I have been at where computing costs did matter were doing extremely specialized, long-running calculations that are inappropriate for lambda. I'm sure there are rare exceptions, but this all smells like premature optimization. Developer salaries are, 9.99 times out of ten, the cost you want to optimize.
sam0x17 5y ago
Another area that this workflow really empowers is it frees you up to have infinite and arbitrary staging environments. In our case we have a GitHub action set up that creates a fully deployed version of the app for every PR automatically, and a bot that comments on the PR with a link to the deployment. You can of course do this with any kind of infrastructure, but only with a serverless sort of architecture is it virtually free to do this kind of thing. On the db side, we allocate extremely tiny instances so it is still quite affordable to just have one running for all of our branches. They are automatically destroyed when the PR is closed so the overhead is basically $5/month for each PR that is open for a whole month (in practice they are open for a few days at most).
- atmosx 5y ago
  This is an interesting use case, thanks for sharing although these days, setting up kubernetes environment emulators is supported by most CI systems out of the box.

freeqaz 5y ago

They bill by the millisecond for usage now, which has helped bring down the cost a ton (at least for web services). And if you don't need fancy stuff, they have a cheaper version of API Gateway now too. Lambda also supports Docker and is pretty damn fast now, so it's less painful to use.

sam0x17 5y ago
Most seed stage startups don't even surpass the free tier in my experience, and depending on the product this can be true for a lot of Series A startups as well.

garethmcc 5y ago

I have worked with many teams and found lambda to be by far more cost effective. Did your calculations include the time lost waiting to deploy solutions while infrastructure gets spun up, the payment for staff or developers spending time putting infrastructure together instead of building solutions, the time spent maintaining the infrastructure, the cost of running servers at 2am when there is no traffic. Perhaps even the cost of running a fat relational database scaled for peak load that needs to bill you by the hour, again even when there is no traffic. Serverless as an architectural pattern is about more than just Lambda and tends to incorporate a multitude of managed services to remove the cost of managment and configuration overhead. When you use IaC tools like Serverless Framework that are built to help developers put together an application as opposed to provisioning resources, it means you can get things up fast and ready to bill you only for usage and that scales amazingly.

daanlo 5y ago
Funnily enough, I have made almost the opposite experience. In my experience IAC and serverless bring all the troubles of dev ops to „regular“ developers. Your plain vanilla mid-level full stack dev now needs to understand not only a bunch about FE & BE code, but also a much bigger bunch about servers, networking, VPCs, etc. than in a non-serverless setup. How do you resolve this in your projects? (Serious question). This is such a big problem for some of the projects that they are now only able to hire senior develops (which brings it‘s own set of problems).
- emteycz 5y ago
  Deploying a Lambda function with Terraform or Pulumi seems to not require knowledge about servers or networking to me
- sam0x17 5y ago
  Yeah, framework-ification of this process has been the real differentiator in the last 5 years that has taken lambda from being obtuse and glitchy to work with to quite a joy if you just lean on your framework. All of that said, I vastly prefer google cloud functions personally and would switch to that in a heartbeat if they had capabilities like API gateway but it's not there yet. I also regret that there isn't a better cross-cloud solution currently, but that's something I have a lot of open source ambitions about creating soon. I don't like serverless that much so stay tuned for something from me in the coming years, probably in Rust.

vorticalbox 5y ago

My biggest issue with lambda are these two limitations. 1. You have a maximum of 30 seconds to reply to the request 2. You cannot stream data from lambda through the api gateway. Though you can stream to s3 etc.

sam0x17 5y ago
Max limit is 15 minutes now. I agree streaming needs work, but if I had to deal with that I'd probably just use naked endpoints.
- vorticalbox 5y ago
  Not when triggered by the api gateway, that is still 30 seconds for things triggered from sqs, s3 etc its 15 minutes.
  - sam0x17 5y ago
    Needing anything more than a few seconds out of API gateway is just bad application design though unless we're talking about websockets or streaming as you said. If it's a webhook, you risk the client hanging up if you do all that work up front (you should instead be scheduling a background lambda that will do it based on the webhook params). If it's an actual user, I'm assuming you're not expecting to have a user wait 30+ seconds for a page to load, so probably some JSON API endpoint with a progress bar on the frontend. In those cases there's really no need to use API gateway as it isn't visible to the user anyway (you could just use your lambda naked in that case). If you're talking about web sockets, yeah, I feel ya. I haven't had to navigate that situation yet but my plan of action is to bypass API gateway entirely and use a naked lambda running at its full execution time, and when we approach the 15 minute boundary, send a command that resets the connection. Don't know if it would work well but I haven't had a need to use web sockets for any projects I work on for a while. For streaming, like you said, maybe an elastic beanstalk cluster is more the way to go depending on your workflow. If you can find a way to get it all to work in Lambda though, would probably be a game changer cost-wise I would expect as long as you figure out a way to deal with resetting every 15 mins.

sam0x17 5y ago

With a spikey workload, it's almost always worth it because we have to scale up 1000x and then 10 mins later scale back down to 1x for the rest of the day, and this can happen any time of day randomly. You can also do this with load balancers but in practice I've found these to be much slower to scale and much more costly with the same workload. For reference, 90% of our bill is database related currently.

exikyut 5y ago
> 90% of our bill is database related currently. Huh. With the context of the rest of the comment, I realize (the very obvious comparison) that a database engine designed to shard to many thousands of small workers could potentially be a very attractive future development path. Iff the current trends in cloud computing (workers, lambda, etc) continues and some other fundamental doesn't come along and overtake. Which is probably (part of) the reason why this doesn't exist, since I think I've basically just described the P=NP of storage engineering :)
- sam0x17 5y ago
  > Huh. With the context of the rest of the comment, I realize (the very obvious comparison) that a database engine designed to shard to many thousands of small workers could potentially be a very attractive future development path. Yes. I've been patiently waiting for the database community to realize this for the last 5 years now :)
  - exikyut 5y ago
    I have no delusions I'd be able to viably make a dent in the area (at least anytime soon), but I do wonder how this would actually work. The optimal solution would of course be to shard both the compute I/O and the storage footprint, so each worker only needed to hold onto maybe 1-100MB of data. Perhaps some existing (simpler) designs could be modified to "hyper-shard" the compute angle, but would still likely require carrying around a large percentage of the database. In any case, you'd need an internal signalling fabric capable of (cost-effectively) handling very bursty many-to-many I/O across thousands of endpoints to make consensus work in realtime. It would honestly be really interesting to see how something like this would work in practice.

jokethrowaway 5y ago

I'd say it's still the case for the majority of the cases. Which is a shame, because I like this idea of having hw limits for your software and being able to efficiently maximise hardware at the datacenter level for redundant, trivial applications (like serving web requests). Most web servers are half idle "just in case" because hardware is cheap and engineers time is expensive. I migrated some mid business (500-1000 people company) lambda setup to ec2 spot instances and a standard app and the costs dropped. It would have been even cheaper on something like heztner, but good luck getting a buy-in from the infra team. I venture most small businesses will have less load than them. Certainly it's not worth it for my tiny side businesses. I was running some calculations for a project though, and if you "abuse" them with lengthy / expensive calculations run very infrequently (think like a cron job), you may end up being quite cost effective.

PetahNZ 5y ago

We trialed switching over to lambda for our worker queues just last month. We went for $500 a month EC2 costs (auto scaling spot fleet), to $500 a day.