5 ms·

I have hard time understanding "Serverless" part... It sounds cool, but there are bunch of servers there they are using. As far as I can manage to understand t

I have hard time understanding "Serverless" part... It sounds cool, but there are bunch of servers there they are using. As far as I can manage to understand that name only has to do with pricing rather then actual servers, but then why is it not called something like "cheap" or "pay as you use"? Maybe I am missing the point here, but this is just a buzzword? (nano-services being the other one, much like micro-services, do we have pico-ones?)

jasonlotito 9y ago
It's not just a buzzword (though some might play it off as one), but the reality is, serverless has a meaning. And it's not that there aren't servers that are there to run your code. Rather, your code can be set to run in production and not be running on any server. It's just not running. It's only running when it needs to run. Another system sits there and when it has an event that comes in that needs to run your code, it starts up your code, passes your code the details, and lets your code run. Once that's done, your code is finished, and it shuts down. This is different from having code running on a server, or deploying your code to a server where it runs. You are paying for the server, regardless of whether it runs. That's what it means.
- buro9 9y ago
  Serverless: 1) The code comes into existence when it is called, and ceases to exist after the request is handled 2) The server on which this happens is managed by someone else. To all intents and purposes there is no server on a logical diagram of your application
  - jasonlotito 9y ago
    Yep. Much more succinct than my explanation. Thanks!
    - buro9 9y ago
      No, thank you. My understanding was vague until I read your comment, I was just summing up that new understanding.
  - mirko22 9y ago
    I will answer here as you kinda summed up what other person said. 1. Same kinda happens with python modules for example 2. All my servers are managed by someone else. You can down vote all you want, but this is in no way different the spawning a bunch of machines somewhere... Also once you start having networking issues there is a server on your diagram... cos all that this is describing is booting up worker nodes. And you can stretch your imagination to call it whatever you like but in the end that is what you are doing.
    - aidos 9y ago
      It's different in that someone else is taking care of the details infrastructure, but to a really high degree. Your function is effectively a single bit of binary executable that will execute once and at termination the fabric it existed on will effectively cease to be. You can definitely say that the lines between that and other forms of execution are blurry but there are quite different modes of operation going on. I have dynamic workers that scale to handle load in our system. I need to know about how the Python binary runs in the system, the upstart jobs that keep the workers running, the queues that push the jobs in, hosted on another machine, the underlying autoscale system, the watchers to figure out how to scale the autoscale system, the network rules between the machines, etc. I know it's kinda the same thing, but it's also kinda not.
      - mirko22 9y ago
        So basically you cut a need for in-house sysadmin? The way you are explaining it sounds ok when you have very small team. And if you look at comments below they seem to have an issue of how to do warmup and cold function calls which suggest that you have to know what the platform is doing anyway (has JIT warmed up, do we need to replicate warmed up functions, how do we cold execute fast etc). So to sum up, it is serverless as long as a 3rd party is in charge of the actual servers and auto-scale infra and if we do it in house it is normal server farm? And sorry if i sound "edgy" but I am just trying to stretch the meaning of actual word "serverless" in my brain to what is being talked about here. I am not a native speaker so that might hinder me as well.
  - deleted 9y ago
    [deleted]
  - qaq 9y ago
    If only someone thought about this earlier oh wait shared hosting
BinaryIdiot 9y ago
The best way to look at "serverless" is that it's a deployment strategy. Instead of deploying a service you are deploying functions or files of code versus a fully functioning service.
- danudey 9y ago
  It took me a while to figure out what they were talking about, but it sounds a lot like Amazon Lambda from what I can tell.
- mirko22 9y ago
  But you spawning a bunch of worker nodes on demand to execute that code?
  - jcrites 9y ago
    The concept of serverless, as I understand it, is that the application developer doesn't need to manage or think about the servers their applications run on. It's not that no one is managing the servers -- it's that the application developer doesn't need to. The developer is building on top of an interface that encapsulates those details. With typical cloud hosting, I need to think about and manage a fleet of hosts from the kernel and operating system on up. I need to think about the hardware and choose a machine type, with a configuration of CPUs, RAM, and disk. I need to choose an OS, and the machine is my responsibility from the init system on upwards, including all of its daemons for SSH, NTP, etc. I need to think about how I'll distribute and install my software onto the machines, and how many machines I need. I need to think about how I'll handle machine failures and replacement. With serverless, the interface to the developer is: specify what application to run, and it runs. I don't have to manage the execution environment that runs the application.
    - KGIII 9y ago
      I'm trying to understand. This sounds kind of opposite to a description given to me for dev-ops. Is that accurate enough for a layman?

jasonlotito 9y ago

It's not just a buzzword (though some might play it off as one), but the reality is, serverless has a meaning. And it's not that there aren't servers that are there to run your code. Rather, your code can be set to run in production and not be running on any server. It's just not running. It's only running when it needs to run. Another system sits there and when it has an event that comes in that needs to run your code, it starts up your code, passes your code the details, and lets your code run. Once that's done, your code is finished, and it shuts down. This is different from having code running on a server, or deploying your code to a server where it runs. You are paying for the server, regardless of whether it runs. That's what it means.

buro9 9y ago
Serverless: 1) The code comes into existence when it is called, and ceases to exist after the request is handled 2) The server on which this happens is managed by someone else. To all intents and purposes there is no server on a logical diagram of your application
- jasonlotito 9y ago
  Yep. Much more succinct than my explanation. Thanks!
  - buro9 9y ago
    No, thank you. My understanding was vague until I read your comment, I was just summing up that new understanding.
- mirko22 9y ago
  I will answer here as you kinda summed up what other person said. 1. Same kinda happens with python modules for example 2. All my servers are managed by someone else. You can down vote all you want, but this is in no way different the spawning a bunch of machines somewhere... Also once you start having networking issues there is a server on your diagram... cos all that this is describing is booting up worker nodes. And you can stretch your imagination to call it whatever you like but in the end that is what you are doing.
  - aidos 9y ago
    It's different in that someone else is taking care of the details infrastructure, but to a really high degree. Your function is effectively a single bit of binary executable that will execute once and at termination the fabric it existed on will effectively cease to be. You can definitely say that the lines between that and other forms of execution are blurry but there are quite different modes of operation going on. I have dynamic workers that scale to handle load in our system. I need to know about how the Python binary runs in the system, the upstart jobs that keep the workers running, the queues that push the jobs in, hosted on another machine, the underlying autoscale system, the watchers to figure out how to scale the autoscale system, the network rules between the machines, etc. I know it's kinda the same thing, but it's also kinda not.
    - mirko22 9y ago
      So basically you cut a need for in-house sysadmin? The way you are explaining it sounds ok when you have very small team. And if you look at comments below they seem to have an issue of how to do warmup and cold function calls which suggest that you have to know what the platform is doing anyway (has JIT warmed up, do we need to replicate warmed up functions, how do we cold execute fast etc). So to sum up, it is serverless as long as a 3rd party is in charge of the actual servers and auto-scale infra and if we do it in house it is normal server farm? And sorry if i sound "edgy" but I am just trying to stretch the meaning of actual word "serverless" in my brain to what is being talked about here. I am not a native speaker so that might hinder me as well.
- deleted 9y ago
  [deleted]
- qaq 9y ago
  If only someone thought about this earlier oh wait shared hosting

BinaryIdiot 9y ago

The best way to look at "serverless" is that it's a deployment strategy. Instead of deploying a service you are deploying functions or files of code versus a fully functioning service.

danudey 9y ago
It took me a while to figure out what they were talking about, but it sounds a lot like Amazon Lambda from what I can tell.
mirko22 9y ago
But you spawning a bunch of worker nodes on demand to execute that code?
- jcrites 9y ago
  The concept of serverless, as I understand it, is that the application developer doesn't need to manage or think about the servers their applications run on. It's not that no one is managing the servers -- it's that the application developer doesn't need to. The developer is building on top of an interface that encapsulates those details. With typical cloud hosting, I need to think about and manage a fleet of hosts from the kernel and operating system on up. I need to think about the hardware and choose a machine type, with a configuration of CPUs, RAM, and disk. I need to choose an OS, and the machine is my responsibility from the init system on upwards, including all of its daemons for SSH, NTP, etc. I need to think about how I'll distribute and install my software onto the machines, and how many machines I need. I need to think about how I'll handle machine failures and replacement. With serverless, the interface to the developer is: specify what application to run, and it runs. I don't have to manage the execution environment that runs the application.
  - KGIII 9y ago
    I'm trying to understand. This sounds kind of opposite to a description given to me for dev-ops. Is that accurate enough for a layman?