4 ms·

Or you know, don't use lambda. If you need that kind of computer power spinning up a large instance, running the job, and then shutting it down is completely vi

by eloff 6y ago

Or you know, don't use lambda. If you need that kind of computer power spinning up a large instance, running the job, and then shutting it down is completely viable. They have per-second billing now on AWS, and you can save even more by using spot instances. Lambda is not cost effective in the CPU/RAM that you get compared to regular instances. It only comes out ahead for very intermittent workloads.

Autowired 6y ago
Your points are valid if your priority is to reduce cost. Totally agree. That said, Lambda has an API and SDK, and concurrency is managed. Warm up is a nightmare if you don't develop specifically for Lambda, but scalability is easy. There are trade-offs, it sucks for many use cases, but I don't think you should just shrug it off.
- eloff 6y ago
  If you have to use beefy lambda instances with multi-threaded workloads? I don't think lambda is the right tool for the job there. I'm not saying it has no value - but that's the opposite of playing to its strengths.
  - Autowired 6y ago
    It all depends, I think. I once used multi-threading to speed up the initialization of a Lambda which was just a "port" of a beefy rest service. It was ported to cut costs and for fault isolation. I managed to gain 2-3 seconds of initialization time, but it was something. A Lambda deployment has the advantage that no one needs to manage it, and faults are isolated between clients. You could argue that if you need these properties your engineering organization has deeper flaws, and you'd be right, but in many companies engineers need to make do with what they get.
    - eropple 6y ago
      > A Lambda deployment has the advantage that no one needs to manage it I assure you that somebody does need to manage it, and if nobody is you are going to eventually hit the wall at speed. I've been called into SEV-1 issues where a Lambda-based web app spontaneously disappeared. (Seasoned AWS heads can probably make a guess as to why.)
      - Autowired 6y ago
        Sure, I was perhaps too hyperbolic. In my case, the advantage was specifically fault isolation for a multi-tenant, low traffic, demanding workload that was traditionally deployed as a physical service.
      - vp8989 6y ago
        "I assure you that somebody does need to manage it" You can always tell who has had to live with non-trivial serverless systems in Prod and who is just parroting the marketing copy.
        Autowired 6y ago
        Let's keep it civilized please. I cited a specific example from my experience, I'm not parroting anything.
eb0la 6y ago
Yes and no: Lambdas (and cloud functions) are to the cloud what Triggers are to Databases. They're very useful to react to events; but they also impose a lock-in. For (very) light usage I feel they're ok. But this is an opinionated feeling. If you want to process a lot of stuff, you need one (or several) instances. If you take a close look at other 'serverless' offerings like KNative in K8s. They do something similar to launching daemon processes but they do launch pods and containers. If you already have K8s, it could be very useful. If not, use a message queue and instances.

by eloff 6y ago

Autowired 6y ago

Your points are valid if your priority is to reduce cost. Totally agree. That said, Lambda has an API and SDK, and concurrency is managed. Warm up is a nightmare if you don't develop specifically for Lambda, but scalability is easy. There are trade-offs, it sucks for many use cases, but I don't think you should just shrug it off.

eloff 6y ago
If you have to use beefy lambda instances with multi-threaded workloads? I don't think lambda is the right tool for the job there. I'm not saying it has no value - but that's the opposite of playing to its strengths.
- Autowired 6y ago
  It all depends, I think. I once used multi-threading to speed up the initialization of a Lambda which was just a "port" of a beefy rest service. It was ported to cut costs and for fault isolation. I managed to gain 2-3 seconds of initialization time, but it was something. A Lambda deployment has the advantage that no one needs to manage it, and faults are isolated between clients. You could argue that if you need these properties your engineering organization has deeper flaws, and you'd be right, but in many companies engineers need to make do with what they get.
  - eropple 6y ago
    > A Lambda deployment has the advantage that no one needs to manage it I assure you that somebody does need to manage it, and if nobody is you are going to eventually hit the wall at speed. I've been called into SEV-1 issues where a Lambda-based web app spontaneously disappeared. (Seasoned AWS heads can probably make a guess as to why.)
    - Autowired 6y ago
      Sure, I was perhaps too hyperbolic. In my case, the advantage was specifically fault isolation for a multi-tenant, low traffic, demanding workload that was traditionally deployed as a physical service.
    - vp8989 6y ago
      "I assure you that somebody does need to manage it" You can always tell who has had to live with non-trivial serverless systems in Prod and who is just parroting the marketing copy.
      - Autowired 6y ago
        Let's keep it civilized please. I cited a specific example from my experience, I'm not parroting anything.

eb0la 6y ago

Yes and no: Lambdas (and cloud functions) are to the cloud what Triggers are to Databases. They're very useful to react to events; but they also impose a lock-in. For (very) light usage I feel they're ok. But this is an opinionated feeling. If you want to process a lot of stuff, you need one (or several) instances. If you take a close look at other 'serverless' offerings like KNative in K8s. They do something similar to launching daemon processes but they do launch pods and containers. If you already have K8s, it could be very useful. If not, use a message queue and instances.