5 ms·

One word of caution about naively porting a regular web app to lambda: since you’re charged for duration, if your app does something like make an API call, you’

• mlhpdx 2y ago
  Not untrue, but also not true. It isn’t a Lambda problem, It’s the problem of running the same old, same old code on lambda. Running clusters of VM/container/instances to “scale up” to transient demand but leaving largely idle (a very, very common outcome) then an event oriented rewrite is going to save a big hunk of money. But yeah, if you keep every instance busy all the time, it is definitely cheaper than lambda busy all the time.
  • paulgb 2y ago
    Sure, if you’re willing to rewrite for an event-based architecture you can avoid the problem, but the post is a framework designed for running on Lambda without that rewrite. One of the stated goals is to have the same container run on EC2 or Fargate.
    • mlhpdx 2y ago
      I understand the point. It’s one in a long line of such enabling tech — all leading to the same outcome.
    • zoover2020 2y ago
      A lot of internal web apps with low TPS can be easily ported to Lambda using these adapters. They should be the main use case IMO.
      • allannienhuis 2y ago
        A lot of internal web apps with low TPS can easily be run on a $5-30/month vps.
        • easton 2y ago
          The minimum cost of running a task on Fargate is under a dollar a month. If you’re a AWS company, you can get cheaper if you take the lock in (not that there’s much lock-in with Fargate)
  • parthdesai 2y ago
    > Running clusters of VM/container/instances to “scale up” to transient demand but leaving largely idle (a very, very common outcome) then an event oriented rewrite is going to save a big hunk of money. If you're using k8s, HPA is handled for you. You just need to define policies/parameters. You're saying as if rewriting an entire app doesn't cost money.
• danappelxx 2y ago
  This is an interesting point. Hangs usually cost $ from user experience, with serverless they cost $ from compute. All the more reason to set strict deadlines on all API calls!
  • hn_throwaway_99 2y ago
    > All the more reason to set strict deadlines on all API calls! I've seen this backfire in production though. E.g. suppose there was a 5 sec limit on an API call, but (perhaps unintentionally) that call was proportional to underlying data volumes or load. So, over time, that call time slowly creeps up. Then it gets to the 5 sec limit, and the call consistently times out. But some client process retries on failure. So, if there was no time limit, the call would complete in, say, 5.2 seconds. But now the call times out every time, so the client just continually retries. Even if the client does exponential backoff, the server is doing a ton of work (and you're getting charged a ton for lambda time), but the client never gets the data they need. Better in my opinion to set alerts first.
• johtso 2y ago
  That's one thing that's really nice about Cloudflare workers, you're billed on CPU time, not duration, so you can happily make slow requests to other services.
  • throwAGIway 2y ago
    How does that work? How can they determine my execution time is spent waiting and not processing?
    • paulgb 2y ago
      They use their own runtime for V8 isolates, so they have a lot of leeway into how they measure/meter it.
    • navaati 2y ago
      At the most basic level, your process is in the D or S states rather than R state. Cloudlflare workers are not exactly Unix processes, but the same concept applies.
    • deleted 2y ago
      [deleted]
    • CaliforniaKarl 2y ago
      When a Linux process is waiting for a socket to have data ready to read (using a system call like select, poll, or epoll), that process is put into a sleep state by the kernel. It continues accruing “wall-clock time” (“wall time”) but stops accruing CPU time. When the kernel has data for the socket, the process starts running again. The above tracking method works for containerized things. For virtualized things, it’s different: When a Linux system has nothing to do (all processes sleeping or waiting), the kernel puts the CPU to sleep. The kernel will eventually be woken by an interrupt from something, at which point things continue. In a virtualized environment, the hypervisor can measure how long the entire VM is running or sleeping.
      • throwAGIway 2y ago
• mfreeman451 2y ago
  [dead]
• chuckadams 2y ago
  Lambdas have a timeout, which defaults to 3 seconds.
  • OJFord 2y ago
    And maxes at 30s (if apigw triggered), GP's point totally valid.
    • coredog64 2y ago
      Used to be a hard quota of 29 seconds for APIGW, but within the last month AWS has updated that to a soft quota. You will have to trade off concurrent calls for the longer APIGW timeout though.
    • datashaman 2y ago
      Use ALB - no limitations on request time.
      • chuckadams 2y ago
        Well, the point is you want a short timeout if your lambda is hanging and you're being billed by the second. If you're not setting it explicitly when you deploy, you're more or less writing Amazon a blank check.
• foundart 2y ago
  Interesting. It makes me wonder about designing "lambda-client-friendly APIs". To reduce the chances of being long-running, the api would be async, meaning: the client makes a request and gets a claim code result quickly, with the api host to process the request separately and then make a callback when done. Lots of issues to consider. Anyone have experience doing this? Would be great to hear about it.
  • mike_d 2y ago
    > It makes me wonder about designing "lambda-client-friendly APIs" If your hammer fails to drive a screw into wood, you don't need to contemplate a new type of low friction wood.
    • krick 2y ago
      Or maybe you do, if screws are so much cheaper than nails.
  • chuckadams 2y ago
    Sounds like webhooks to me -- a use case Lambda excels at.
    • foundart 2y ago
      Thanks! I think you're right. To go beyond my original question: In terms of how I have thought about them before, webhooks are similar, but not quite the same thing. I've really only dealt with webhooks when the response was delayed because of a need for human interaction, for example: sending a document for e-signature and then later receiving notifications when the document is viewed and then signed or rejected. I haven't experienced much need to make REST APIs async, only in cases where the processing was generally always very slow for reasons that couldn't be optimized away. I haven't seen much advocacy for it either. However, if we think about lambda-based clients, then it makes a lot more sense to provide async apis. Why have both sides paying for the duration, even if the duration is relatively short? update: Whether or not it's cheaper for the client depends on the granularity of the pricing of the client's provider. For AWS, it seems to be per second of duration, so async would be more expensive for APIs that execute quickly.
• jmull 2y ago
  I think "a regular web app" is interactive... 3s would rarely be acceptable, much less 30s. Not that it never happens, but it should be rare enough that the cost of the lambda isn't the main concern. (Or if it's not rare, your focus should be on fixing the issue, not really the cost of the lambdas.) Anyway, I think you'd typically limit the lambda run time limit to something a lot shorter than 30 sec.
• multani 2y ago
  What is the pattern to use on Lambda if you actually have to call out other services, which may, sometimes, take a long time to answer? Do you make requests with a shorter timeout and have your Lambda fail when it triggers? Do you delegate long calls to a non-Lambda service?
  • roncesvalles 2y ago
    It seems like Lambda is not suited for such "hanging" use cases. To me the best use case for Lambda is for an API call that might be made very infrequently, like say 50 times a day. Doing the same with a VM instance (remember, it has to be HA, secure etc) is probably not worth the effort.
  • moribvndvs 2y ago
    In a case where a dependency has a consistent high latency and you can’t avoid it, I’d run the numbers and see if it’s more worthwhile to just run your app on ECS or something instead.
    • Aeolun 2y ago
      I find that running your app on ECS is generally a great way to just do away with a whole class of problems. I’ve never found lambda to do away with any of the issues I encounter on ECS.
      • moribvndvs 2y ago
        I don’t feel great about lambda (outside of jobs processing and such) as it sometimes feels like you took your application and broke it into a thousand little footguns where a mistake or bad actor can tank your business, but if your company experiences very spikey workloads or not enough income to pay for 24/7 ECS and such, I can see the appeal.
  • dragonwriter 2y ago
    If you have enougu volume to warrant it, probably re-architecting the lambdas so the before/after part of the calls is a separate invocation, with an adapter service living on ECS that gets a call from the “before” lambda, handles the remote request and response, the calls the “after” lambda with the response. The simpler solution is often to just lift the app from lambda to ECS without internal changes
• OJFord 2y ago
  A corollary is that if you have your lambdas call your other lambdas call...
  • thefourthchime 2y ago
    lambda blocking on calling other lambdas is a bit of an antipattern. If it can be avoided and use something like sqs to call the other lambda, die and then resume on a notification from the other lambda. That can tricky, but if costs are getting bad it’s the way.
    • OJFord 2y ago
      Absolutely. Wasn't saying it's a good idea.
• thefourthchime 2y ago
  I've done an internal website using lambdas. It works fine, I just use jinja2 templates and load html files that are part of the deployed file system. Any other logic is just normal SPA stuff. If you set the min concurrency to 1 it's pretty snappy as well.
• leef 2y ago
  That is kind of the point of this repo. If your API implementation is too expensive for lambda move the same container to run on EKS/ECS fargate or ec2. The opposite holds as well - if you can save money by moving it from fargate to lambda then you can use the same container.
• okigan 2y ago
  As @leef mentioned, you should transition between Lambda and <another offering> based on the current load. I've published LambdaFlex as an Infrastructure as Code (IaC) template. It automatically scales and manages traffic between AWS Lambda and AWS Fargate [1]. This setup leverages the strengths of both services: rapid scaling, scaling down to zero, and cost-effectiveness. [1] GitHub: https://github.com/okigan/lambdaflex https://github.com/okigan/lambdaflex