5 ms·

Thanks for explanation, it's somehow clearer to me, now. There's one thing I still don't understand: doesn't this mean it's basically just a small server app wi

Thanks for explanation, it's somehow clearer to me, now. There's one thing I still don't understand: doesn't this mean it's basically just a small server app with a standardized api (as in, api must be implemented in a certain way which allow to call its endpoints as if we were calling functions directly)? What is the specificity of lambda? (beside the pricing style, making pay for requests rather than app execution time)

IanCal 9y ago
Yes, in a way. You can also use it to run code on data in S3 or other aws services. For example I need to munge some data somewhat regularly, which is stored as json on S3. I can trigger it, and have about a thousand processes running in a few seconds, and my large chunk of json processed very quickly. I don't need to maintain any systems for this to work and it's cheap enough it's not worth me worrying about. Though S3 select might supercede a bunch of my use cases.
- oelmekki 9y ago
  Oh, I see: it's not just that it's a simple app with payment on endpoint access, it's that it can spawn tons on this app very quickly. Am I correct to assume to ideal use case for that is to replace what is typically implemented as a background workers for webservices?
  - IanCal 9y ago
    I've not used it much outside my own area but yes I think that's a very good use case. Particularly if there's a "process some files" part. The classic example is thumbnails for images, you can point a very simple bit of imagemagik calling code at a bucket and say "any time a file is dropped in here, create a thumbnail and put it over here" and it'll scale when you have a bunch of images dropped in and cost nothing when nothing is happening. Not perfect for all use cases, although some people do seem to enjoy running as much stuff in lambda as possible, but when it matches what you need it can be a surprisingly simple solution to quite annoying problems.
always_good 9y ago
> Thanks for explanation, it's somehow clearer to me, now. Seems weird to completely disarm your "thanks" with "somehow".
- encoderer 9y ago
  He probably meant somewhat. English is hard.
  - oelmekki 9y ago
    Indeed, TIL they are not synonymous :) (non native speaker)
owaislone 9y ago
Yes, you are right. That's almost it. There are even some open source function-as-a-service platforms out there that do this. The advantage with lambda is that it is dealt with by Amazon so it is virtually infinitely scalable. Also, it integrates with tightly with a ton of AWS services which makes it a great option if you are already invested in AWS.
- oelmekki 9y ago
  I see, thanks for confirming this. I was initially skeptic about lambda when it was first released, thinking "so after heroku which makes us pay per process, now we must pay per function call?", but I know better than trusting my doubts about a new tech, I've seen too many people focusing on the parts from a new tech resembling an old one, totally missing what is new. Would you agree with this statement? => what sets lambda apart is that it boots so fast that it's legit to start one only to call one function, which in turns, thanks to aws infrastructure, allows to massively parallelize short lived tasks.
  - owaislone 9y ago
    Yes, I'd agree with that but to me Lambda is much more than that. It's not only suitable for very short running tasks. In fact it is suitable for everything other than very long running tasks. We can build proper APIs and web services on top of lambda and literally only pay for the exact resources we consume. We never have to worry about managing infrastructure, handling auto-scaling, etc. AWS recently also introduced a "serverless" database offering that also comes up when you need it and then goes to sleep. It can scale "infinitely" as well. I see majority of my workloads implemented on top of Lambda + ECS/Fargate/Kubernestes in near future. Lambda for all short running jobs (1-5mins) like image processing, emails, notifications, web services, APIs, glue code, state machines, etc and ECS for long running tasks like data processing, DB syncs, backups, video encoding etc etc.

IanCal 9y ago

Yes, in a way. You can also use it to run code on data in S3 or other aws services. For example I need to munge some data somewhat regularly, which is stored as json on S3. I can trigger it, and have about a thousand processes running in a few seconds, and my large chunk of json processed very quickly. I don't need to maintain any systems for this to work and it's cheap enough it's not worth me worrying about. Though S3 select might supercede a bunch of my use cases.

oelmekki 9y ago
Oh, I see: it's not just that it's a simple app with payment on endpoint access, it's that it can spawn tons on this app very quickly. Am I correct to assume to ideal use case for that is to replace what is typically implemented as a background workers for webservices?
- IanCal 9y ago
  I've not used it much outside my own area but yes I think that's a very good use case. Particularly if there's a "process some files" part. The classic example is thumbnails for images, you can point a very simple bit of imagemagik calling code at a bucket and say "any time a file is dropped in here, create a thumbnail and put it over here" and it'll scale when you have a bunch of images dropped in and cost nothing when nothing is happening. Not perfect for all use cases, although some people do seem to enjoy running as much stuff in lambda as possible, but when it matches what you need it can be a surprisingly simple solution to quite annoying problems.

always_good 9y ago

> Thanks for explanation, it's somehow clearer to me, now. Seems weird to completely disarm your "thanks" with "somehow".

encoderer 9y ago
He probably meant somewhat. English is hard.
- oelmekki 9y ago
  Indeed, TIL they are not synonymous :) (non native speaker)

owaislone 9y ago

Yes, you are right. That's almost it. There are even some open source function-as-a-service platforms out there that do this. The advantage with lambda is that it is dealt with by Amazon so it is virtually infinitely scalable. Also, it integrates with tightly with a ton of AWS services which makes it a great option if you are already invested in AWS.

oelmekki 9y ago
I see, thanks for confirming this. I was initially skeptic about lambda when it was first released, thinking "so after heroku which makes us pay per process, now we must pay per function call?", but I know better than trusting my doubts about a new tech, I've seen too many people focusing on the parts from a new tech resembling an old one, totally missing what is new. Would you agree with this statement? => what sets lambda apart is that it boots so fast that it's legit to start one only to call one function, which in turns, thanks to aws infrastructure, allows to massively parallelize short lived tasks.
- owaislone 9y ago
  Yes, I'd agree with that but to me Lambda is much more than that. It's not only suitable for very short running tasks. In fact it is suitable for everything other than very long running tasks. We can build proper APIs and web services on top of lambda and literally only pay for the exact resources we consume. We never have to worry about managing infrastructure, handling auto-scaling, etc. AWS recently also introduced a "serverless" database offering that also comes up when you need it and then goes to sleep. It can scale "infinitely" as well. I see majority of my workloads implemented on top of Lambda + ECS/Fargate/Kubernestes in near future. Lambda for all short running jobs (1-5mins) like image processing, emails, notifications, web services, APIs, glue code, state machines, etc and ECS for long running tasks like data processing, DB syncs, backups, video encoding etc etc.