3 ms·

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?
  - jcrites 9y ago
    I wouldn't consider serverless to be the opposite of DevOps. I'd actually consider those concepts to be largely orthogonal. Serverless and classic server environments are different kinds of system to manage. Classic operations vs. DevOps is about how you manage your systems, and who has responsibility for them. In classic operations, software development and operations are separate teams with different responsibilities. DevOps combines these two functions into a single team (hence DevOps). Serverless applications are still a system that needs to be managed; it's just less responsibility and effort than the traditional model. Consider: if newly released code contains a defect that's impacting the larger system, who has responsibility for detecting the problem and rolling it back? This concern exists with both server and serverless platforms, and DevOps vs. classic operations would have different answers.
    - KGIII 9y ago
      Excellent, thanks. That sums it up wonderfully. I'm retired and we had separate teams with a liaison between the two, pretty much since our inception. A part of me thinks it's a good idea, but I'd worry about depth of knowledge in both disciplines, but I digress.
  - digi_owl 9y ago
    To this layman it seems to fit like a tee with devops, as it allows the devs to get the ops out of their hair by having them reside in a different company altogether. Thus there is no ops to go "no way no how" where devs want to introduce some new shiny to the stack, as their only interaction is over a web api...
- deleted 9y ago
  [deleted]

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?
- jcrites 9y ago
  I wouldn't consider serverless to be the opposite of DevOps. I'd actually consider those concepts to be largely orthogonal. Serverless and classic server environments are different kinds of system to manage. Classic operations vs. DevOps is about how you manage your systems, and who has responsibility for them. In classic operations, software development and operations are separate teams with different responsibilities. DevOps combines these two functions into a single team (hence DevOps). Serverless applications are still a system that needs to be managed; it's just less responsibility and effort than the traditional model. Consider: if newly released code contains a defect that's impacting the larger system, who has responsibility for detecting the problem and rolling it back? This concern exists with both server and serverless platforms, and DevOps vs. classic operations would have different answers.
  - KGIII 9y ago
    Excellent, thanks. That sums it up wonderfully. I'm retired and we had separate teams with a liaison between the two, pretty much since our inception. A part of me thinks it's a good idea, but I'd worry about depth of knowledge in both disciplines, but I digress.
- digi_owl 9y ago
  To this layman it seems to fit like a tee with devops, as it allows the devs to get the ops out of their hair by having them reside in a different company altogether. Thus there is no ops to go "no way no how" where devs want to introduce some new shiny to the stack, as their only interaction is over a web api...
deleted 9y ago
[deleted]