5 ms·

This looks neat. I am new to the whole serverless concept, can someone explain how it works? Let's say I have to do some processing on the server (schedule som

This looks neat. I am new to the whole serverless concept, can someone explain how it works? Let's say I have to do some processing on the server (schedule some cron jobs, generate a PDF or send an email), how do I go about doing that? Do I use AWS Lambda for that?

daliwali 10y ago
Spoiler alert: serverless is made of servers. But seriously what they mean is that you rent an allotted amount of resources on a server farm to run your application for a short period of time, and then the resources are freed again. Not all applications will fit this environment, such as any embedded databases, persistent connections, and so on.
- Etheryte 10y ago
  I never understood the naming for this trend. It's misleading at best.
  - mattzito 10y ago
    I think it's that people assumed (as I did) that everyone would say, "Well, of course, there's not "no servers", because that would be like saying "computerless" or "processorless", but it is practical to say serverless and mean that you don't have to provision, administer, scale, or retire servers, nor do you have to pay for persistent compute resources rather than simply execution" But that's a mouthful, so "serverless" seems to fit the bill outside of what feels a bit like pedantry.
    - dualogy 10y ago
      > mean that you don't have to provision, administer, scale, or retire servers, nor do you have to pay for persistent compute resources rather than simply execution Given all the work this appears to save one, there's a curious explosion of "serverless" articles, frameworks, APIs, 'practices', crash-courses, workshops, talks .. ah well, par for the course with anything tech that gains a catchy moniker. (Perhaps that's why FP doesn't take off quite as much, "Monads" should have been called "Promises" 30 years ago, and Peano Numbers "numberless maths"!)
  - collyw 10y ago
    Think of it as serverless pricing model.
  - jbergens 10y ago
    I think "nanoservices" would have been a better name.
    - ultimatejs 10y ago
      nanoservices isn't specific enough. serverless has great meaning to initiated web developers. i for one know exactly what they mean by that and always did, whereas nanoservices, to me at least, could mean all sorts of things.
jeppz 10y ago
Yea you can totally use Lambda for that. For example you can schedule triggers in Cloudwatch that runs a lambda at intervals to do whatever you need, for example generate a pdf and put it on s3 where you or your users can access it directly.
- cyberferret 10y ago
  +1 for CloudWatch scheduled triggers. We used to have a few EC2 worker instances running cron jobs, but since switching to CW scheduled triggers and Lambda, have managed to save a bunch of $$$ on running instances that were doing menial work.
deleted 10y ago
[deleted]
dahart 10y ago
I hadn't heard the term before, but these pages have good explanations: https://en.m.wikipedia.org/wiki/Serverless_computing https://en.m.wikipedia.org/wiki/Serverless_computing https://aws.amazon.com/lambda/ https://aws.amazon.com/lambda/ "Run code without provisioning or managing servers [...] pay only for the time you consume" Makes sense, but based on the name, I initially expected to see a framework that lets you spin up an app without writing any backend code, perhaps like using Firebase but more framework and less service. Then I thought there are even more ways to remove the server. Maybe there should be multiple levels of "serverless". Type 0 serverless is an html file. Type 1 serverless is a static web page. Type 2 serverless is a dynamic app with a backend service; no writing backend code. Type 3 serverless is a dynamic app plus backend code with a backend management service; no provisioning or managing backend instances. :P
lostcolony 10y ago
Sure. I've been working professionally with it since shortly after the API Gateway was made available in 2015, and am actually giving a couple of talks on it later this year, so I may be able to give a decently thorough, abbreviated discussion of it, at least in the AWS world. Essentially, the motivation is to abstract away from caring about the underlying operating system and virtual machine. That is, in the same way that a VM attempts to abstract away from the underlying hardware (so that you, the system operator, need not care about it), serverless attempts to abstract away from the underlying VM and operating system. You the developer shouldn't care about that; you should just care about your code. So how is that achieved? Well, in AWS, Lambda is a key portion of it. They are small units of execution, defined by arguments in, arguments out, and side effects (same as a function in any language). They have access to a set amount of cpu/memory resources, as well as a bit of hard disk scratch space (note: this space is -not- guaranteed to exist across function invocations; any state you wish to persist between functions must be stored in another services, such as RDS, Dynamo, S3, etc). So you can certainly create a function that, when called, executes some bit of functionality (based on the input, or not, as appropriate). What then matters is how it is called. Per another comment, you can trigger them via Cloudwatch to execute at a scheduled time (so perfect for cron jobs). You can also cause them to trigger based on certain events in AWS (such as S3 uploads; whenever a file lands in S3, spin up a lambda to process it in some way). But more than that, you can stick an HTTP(S) endpoint in front of them to create a RESTful API. You can do this via the AWS API Gateway. You map how the HTTP request gets passed into the lambda, and then your code can process it whenever the HTTP(S) endpoint is hit. So with this you effectively have a REST API that will scale predictably. There is cost associated with it (and you have to evaluate whether the cost makes sense; it may not if you have already invested in sysops style resources, or if your load is so high that the Lambda + API Gateway cost is prohibitive compared with running equivalent EC2 instances), but that cost scales with use. And there are a few other caveats as well to learn about and be aware of. But if you then rely on other AWS services for things like data storage, messaging, etc (including email sending; have a look at AWS SES) you can create an entire backend without any servers that you, personally, have to maintain or care about. 'Serverless' frameworks tend to focus on the Lambda + API Gateway integration, to provide you with a developer environment that you can run locally, and then with a single command deploy to AWS, getting both your function and your API in place. They generally have no knowledge of other related infrastructure (which you will likely need, though you can likely configure just once and be done with it; unlike a lambda, you're not changing it frequently)

daliwali 10y ago

Spoiler alert: serverless is made of servers. But seriously what they mean is that you rent an allotted amount of resources on a server farm to run your application for a short period of time, and then the resources are freed again. Not all applications will fit this environment, such as any embedded databases, persistent connections, and so on.

Etheryte 10y ago
I never understood the naming for this trend. It's misleading at best.
- mattzito 10y ago
  I think it's that people assumed (as I did) that everyone would say, "Well, of course, there's not "no servers", because that would be like saying "computerless" or "processorless", but it is practical to say serverless and mean that you don't have to provision, administer, scale, or retire servers, nor do you have to pay for persistent compute resources rather than simply execution" But that's a mouthful, so "serverless" seems to fit the bill outside of what feels a bit like pedantry.
  - dualogy 10y ago
    > mean that you don't have to provision, administer, scale, or retire servers, nor do you have to pay for persistent compute resources rather than simply execution Given all the work this appears to save one, there's a curious explosion of "serverless" articles, frameworks, APIs, 'practices', crash-courses, workshops, talks .. ah well, par for the course with anything tech that gains a catchy moniker. (Perhaps that's why FP doesn't take off quite as much, "Monads" should have been called "Promises" 30 years ago, and Peano Numbers "numberless maths"!)
- collyw 10y ago
  Think of it as serverless pricing model.
- jbergens 10y ago
  I think "nanoservices" would have been a better name.
  - ultimatejs 10y ago
    nanoservices isn't specific enough. serverless has great meaning to initiated web developers. i for one know exactly what they mean by that and always did, whereas nanoservices, to me at least, could mean all sorts of things.

jeppz 10y ago

Yea you can totally use Lambda for that. For example you can schedule triggers in Cloudwatch that runs a lambda at intervals to do whatever you need, for example generate a pdf and put it on s3 where you or your users can access it directly.

cyberferret 10y ago
+1 for CloudWatch scheduled triggers. We used to have a few EC2 worker instances running cron jobs, but since switching to CW scheduled triggers and Lambda, have managed to save a bunch of $$$ on running instances that were doing menial work.

deleted 10y ago

[deleted]

dahart 10y ago

I hadn't heard the term before, but these pages have good explanations: https://en.m.wikipedia.org/wiki/Serverless_computing https://en.m.wikipedia.org/wiki/Serverless_computing https://aws.amazon.com/lambda/ https://aws.amazon.com/lambda/ "Run code without provisioning or managing servers [...] pay only for the time you consume" Makes sense, but based on the name, I initially expected to see a framework that lets you spin up an app without writing any backend code, perhaps like using Firebase but more framework and less service. Then I thought there are even more ways to remove the server. Maybe there should be multiple levels of "serverless". Type 0 serverless is an html file. Type 1 serverless is a static web page. Type 2 serverless is a dynamic app with a backend service; no writing backend code. Type 3 serverless is a dynamic app plus backend code with a backend management service; no provisioning or managing backend instances. :P

lostcolony 10y ago

Sure. I've been working professionally with it since shortly after the API Gateway was made available in 2015, and am actually giving a couple of talks on it later this year, so I may be able to give a decently thorough, abbreviated discussion of it, at least in the AWS world. Essentially, the motivation is to abstract away from caring about the underlying operating system and virtual machine. That is, in the same way that a VM attempts to abstract away from the underlying hardware (so that you, the system operator, need not care about it), serverless attempts to abstract away from the underlying VM and operating system. You the developer shouldn't care about that; you should just care about your code. So how is that achieved? Well, in AWS, Lambda is a key portion of it. They are small units of execution, defined by arguments in, arguments out, and side effects (same as a function in any language). They have access to a set amount of cpu/memory resources, as well as a bit of hard disk scratch space (note: this space is -not- guaranteed to exist across function invocations; any state you wish to persist between functions must be stored in another services, such as RDS, Dynamo, S3, etc). So you can certainly create a function that, when called, executes some bit of functionality (based on the input, or not, as appropriate). What then matters is how it is called. Per another comment, you can trigger them via Cloudwatch to execute at a scheduled time (so perfect for cron jobs). You can also cause them to trigger based on certain events in AWS (such as S3 uploads; whenever a file lands in S3, spin up a lambda to process it in some way). But more than that, you can stick an HTTP(S) endpoint in front of them to create a RESTful API. You can do this via the AWS API Gateway. You map how the HTTP request gets passed into the lambda, and then your code can process it whenever the HTTP(S) endpoint is hit. So with this you effectively have a REST API that will scale predictably. There is cost associated with it (and you have to evaluate whether the cost makes sense; it may not if you have already invested in sysops style resources, or if your load is so high that the Lambda + API Gateway cost is prohibitive compared with running equivalent EC2 instances), but that cost scales with use. And there are a few other caveats as well to learn about and be aware of. But if you then rely on other AWS services for things like data storage, messaging, etc (including email sending; have a look at AWS SES) you can create an entire backend without any servers that you, personally, have to maintain or care about. 'Serverless' frameworks tend to focus on the Lambda + API Gateway integration, to provide you with a developer environment that you can run locally, and then with a single command deploy to AWS, getting both your function and your API in place. They generally have no knowledge of other related infrastructure (which you will likely need, though you can likely configure just once and be done with it; unlike a lambda, you're not changing it frequently)