3 ms·

I thought lambdas are practical when they're called rarely, with a surge of traffic occasionally? So that you don't pay for the servers when they're unused, and

by kgeist 3y ago

I thought lambdas are practical when they're called rarely, with a surge of traffic occasionally? So that you don't pay for the servers when they're unused, and occasionally you can withstand black friday traffic. If a lambda is called 6 times per second, I suspect the underlying VMs/containers that power lambdas are rarely shut down (I don't know how AWS works but that's how it works in another cloud provider I'm familiar with - they wait for a little for new requests before shutting down the container). So might've as well just used an always-on server. I also wonder why their calculations show that 6rps (that's what their "17 mln monthly lambda invocations" really means) would require 25 servers. We have a single mediocre VM which serves around 6 rps on average as well without issues... Although, of course, it all depends on what kind of load each request has. We don't do number crunching and most of the time is spent in the database.

civilitty 3y ago
If they’re called rarely, they have poor latency due to cold start times. IMO lambdas are most practical when someone else in the org is responsible for spinning up VMs and your boss is in a pissing match with their boss, preventing you from getting any new infrastructure to get work done. The technical merits rarely have anything to do with it.
- steveBK123 3y ago
  "it costs 2x as much but doesn't require me to navigate my messed up IT org" is an underappreciated motivation for a lot of architectures you see people pump. Your IT org political problems may not match, and therefore their architecture may not either. Also there's the question of what problem you are trying to scale at what scale, with what resiliency/uptime requirements, etc...
  - jamesfinlayson 3y ago
    Agreed - I worked at a company that couldn't get some expensive security tool approved so they just bought it off AWS Marketplace. The AWS bill was high enough that the increase wasn't questioned.
    - steveBK123 3y ago
      I've worked at companies doing $2B in profits that had multi-month arguments about $100k on-prem production server refreshes due to more customers doing more transactions. And yet I've been at companies 80% smaller/poorer who didn't notice $60k development environment costs because they were blended into a gigantic AWS bill. The incentives are very very bad.
tetha 3y ago
Mh, we've been looking at e.g. OpenFaaS to implement rare or slow and resource intensive processes as functions so they don't have to run all the time. Think of customer provisioning, larger data exports, model trainings and such things. Here, a slow startup might add a few seconds to a few minute long process. But our outcome is: Outside of really heavyweight processes like model trainings, it's a lot of infrastructural effort to run something like this on our own systems, opposed to just sticking that code into a rarely called REST endpoint in some application we're already running anyway. We'd need a lot more volume of somewhat rarely executed tasks to make it worth running it.
islewis 3y ago
> why their calculations show that 6rps (that's what their "17 mln monthly lambda invocations" really means) would require 25 servers I'm guessing that it has something to do with the average job taking 15 minutes. 6rps represents 6 jobs being created per second, but each one takes 15 minutes to run until completion. Another way to look at it is each second 90 minutes of lambda work is created. If you consider 15 minutes the rolling window, which looks like a fair assumption based on the graph provided, there could be up to 5400 (15 min x 60 sec x 6 rps) functions running at once. Working backwards, 25 medium instance provide (25 instances x 4 GB mem) an 100gb memory pool, or 100,000mb. That leaves around ~18mb for each of those 5400 jobs, if you don't consider OS resource overhead. Looking at averages in this situation very possibly can give a warped perception of reality, but 25 instances doesn't seem out of the realm of possibility. I'm sure they have much more relevant metrics to back up that number as well. Whether the functions really need this much time to run is another issue entirely, and hard to answer with the information given.

by kgeist 3y ago

civilitty 3y ago

If they’re called rarely, they have poor latency due to cold start times. IMO lambdas are most practical when someone else in the org is responsible for spinning up VMs and your boss is in a pissing match with their boss, preventing you from getting any new infrastructure to get work done. The technical merits rarely have anything to do with it.

steveBK123 3y ago
"it costs 2x as much but doesn't require me to navigate my messed up IT org" is an underappreciated motivation for a lot of architectures you see people pump. Your IT org political problems may not match, and therefore their architecture may not either. Also there's the question of what problem you are trying to scale at what scale, with what resiliency/uptime requirements, etc...
- jamesfinlayson 3y ago
  Agreed - I worked at a company that couldn't get some expensive security tool approved so they just bought it off AWS Marketplace. The AWS bill was high enough that the increase wasn't questioned.
  - steveBK123 3y ago
    I've worked at companies doing $2B in profits that had multi-month arguments about $100k on-prem production server refreshes due to more customers doing more transactions. And yet I've been at companies 80% smaller/poorer who didn't notice $60k development environment costs because they were blended into a gigantic AWS bill. The incentives are very very bad.

tetha 3y ago

Mh, we've been looking at e.g. OpenFaaS to implement rare or slow and resource intensive processes as functions so they don't have to run all the time. Think of customer provisioning, larger data exports, model trainings and such things. Here, a slow startup might add a few seconds to a few minute long process. But our outcome is: Outside of really heavyweight processes like model trainings, it's a lot of infrastructural effort to run something like this on our own systems, opposed to just sticking that code into a rarely called REST endpoint in some application we're already running anyway. We'd need a lot more volume of somewhat rarely executed tasks to make it worth running it.

islewis 3y ago

> why their calculations show that 6rps (that's what their "17 mln monthly lambda invocations" really means) would require 25 servers I'm guessing that it has something to do with the average job taking 15 minutes. 6rps represents 6 jobs being created per second, but each one takes 15 minutes to run until completion. Another way to look at it is each second 90 minutes of lambda work is created. If you consider 15 minutes the rolling window, which looks like a fair assumption based on the graph provided, there could be up to 5400 (15 min x 60 sec x 6 rps) functions running at once. Working backwards, 25 medium instance provide (25 instances x 4 GB mem) an 100gb memory pool, or 100,000mb. That leaves around ~18mb for each of those 5400 jobs, if you don't consider OS resource overhead. Looking at averages in this situation very possibly can give a warped perception of reality, but 25 instances doesn't seem out of the realm of possibility. I'm sure they have much more relevant metrics to back up that number as well. Whether the functions really need this much time to run is another issue entirely, and hard to answer with the information given.