3 ms·

Yeah also heroku and the whole generation of “PaaS” I was never quite sure why we got the name “serverless”, or where it came from, since there were many such

by chubot 2y ago

Yeah also heroku and the whole generation of “PaaS” I was never quite sure why we got the name “serverless”, or where it came from, since there were many such products a few years before, and they already had a name App engine had both batch workers and web workers too, and Heroku did too They were both pre-docker, and maybe that makes people think they were different? But I think lambda didn’t launch with docker either

Uehreka 2y ago
PaaS, Containerization and Serverless are different concepts. App Engine is PaaS: You provide your app to the service in a runnable form (maybe a container image, maybe not) and they spin up a dedicated server (or slice of a server) to run it continuously. Lambda is Serverless: You provide them a bit of code and a condition under which that code should run. They charge you only when that thing happens and the code runs. How they make that happen (deploy it to a bajillion servers? Only deploy it when it’s called?) are implementation details that are abstracted from the user/developer as long as Lambda makes sure that the code runs whenever the condition happens. So with PaaS you have to pay even if you have 0 users, and when you scale up you have to do so by spinning up more “servers” (which may result in servers not being fully utilized). With Serverless you pay for the exact amount of compute you need, and 0 if your app is idle.
- chubot 2y ago
  > They charge you only when that thing happens and the code runs. That's how App Engine worked in 2008, and it looks like it still works that way: https://cloud.google.com/appengine/pricing https://cloud.google.com/appengine/pricing Apps running in the flexible environment are deployed to virtual machine types that you specify. These virtual machine resources are billed on a per-second basis with a 1 minute minimum usage cost. This applied to both the web workers and the batch workers It was "serverless" in 2008! > spin up a dedicated server (or slice of a server) to run it continuously. Absolutely NOT true of App Engine in 2008, and I'm pretty sure Heroku in 2008 too!
- tantalor 2y ago
  I recall you could configure app engine with maximum number of instances you wanted, but you definitely weren't charged if usage was 0. They would start the instances as needed. The fact that lambda would automatically scale to meet whatever QPS you got sounds terrifying.
randomdata 2y ago
> I was never quite sure why we got the name “serverless”, or where it came from Serverless refers to the software not being a server (usually implied to be a HTTP server), as was the common way to expose a network application throughout the 2010s, instead using some other process-based means to see the application interface with an outside server implementation. Hence server-less. It's not a new idea, of course. Good old CGI is serverless, but CGI defines a specific protocol whereas serverless refers to a broad category of various implementations.
- bloppe 2y ago
  Pedantry police here. I would define serverless to mean that all the hardware is completely abstracted away. For instance, on EC2, you have to pick an instance type. You pick how much memory and compute you need. On a managed kuberenetes cluster, you still have to think about nodes. On a serverless platform, though, you have no idea how many computers or what kinds of computers are actually running your code. It just runs when it needs to. Of course there's still an HTTP server somewhere, though. So, you could run a CGI script on a serverless platform, or a "serverful" one. You could even run it locally. https://en.wikipedia.org/wiki/Serverless_computing https://en.wikipedia.org/wiki/Serverless_computing Per wikipedia: "Serverless is a misnomer in the sense that servers are still used by cloud service providers to execute code for developers. However, developers of serverless applications are not concerned with capacity planning, configuration, management, maintenance, fault tolerance, or scaling of containers, virtual machines, or physical servers."
  - randomdata 2y ago
    For all intents and purposes, when is the hardware not fully abstracted away? Even through the 2010s when running as a server was the norm, for the most part you could throw the same code onto basically any hardware without a second thought. But pedantically, serverless is to be taken literally. It implies that there is no server in your application.
    - bloppe 2y ago
      EC2 and managed kubernetes are two examples where you still have to think about hardware.
conradev 2y ago
Serverless, to me, is purely about efficiency. One way to measure that is the time for a "cold start" or "going from a state where you pay no money to one where you pay money". These gains in efficiency remove the need for over-provisioning and in many cases allow you to pass these savings onto the consumer (if you want to). Heroku is a few seconds: > It only takes a few seconds to start a one-off dyno process or to scale up a web or worker process. Lambda created Firecracker to be snappier: > The duration of a cold start varies from under 100 ms to over 1 second. I think App Engine is in the same ballpark as Lambda (and predated it). Fly.io uses Firecracker too: > While Fly Machine cold starts are extremely fast, it still takes a few hundred milliseconds, so it’s still worth weighing the impact it has on performance. but WASM is yet an order of magnitude faster and cheaper: > Cloudflare Workers has eliminated cold starts entirely, meaning they need zero spin up time. This is the case in every location in Cloudflare's global network. WASM is currently limited in what it can do, but if all you're doing is manipulating and serving HTML, it's fantastic at that.
dartos 2y ago
When lambda came out and serverless started getting big, most scrappy startups hired many frontend devs. It was the heydays of SPAs, light backends, and thick frontends. “Serverless” is a great way to say “you don’t need to be a backend dev or even know anything about backend to deploy with us” And it worked really really well. Then people realized that they should know a thing or two about backend. I always really hated that term.
friendzis 2y ago
Serverless is indeed a weird name if you know what you are talking about. I was dumbfounded by the term until I met people who actually thought of anything beyond pushing to git as "the server". Backend returns 4xx/5xx? The server is down. Particular data is not available in this instance and app handles this error path poorly? The server is down. There is no API to call for this, how do I implement "the server"? Some people still hold the worldview that application deployment is similar to mod-php where source files are yoloed to live filesytem. In this worldview, ignorant of complexities in operations, serverless is perfectly fitting marketing term, much like Autopilot, first chosen by Musk, chef's kiss.
- randomdata 2y ago
  > Serverless is indeed a weird name if you know what you are talking about. It is a perfectly logical name if you know what you are talking about and are familiar with the history of how these so-called serverless applications used to be developed. Which is to say that back in the day, once CGI fell out of fashion, the applications became servers themselves. You would have a listening HTTP server right within the application, often reverse proxied through something like Apache or nginx, and that is how it would be exposed to the world. The downside of this model is that your application always needs to be resident in order to serve requests, and, from a scaling perspective, you need to predict ahead of time many server instances are needed to handle the request load. This often resulted in poor resource utilization. Now with a return to back to the CGI-esq model, where you have managing servers call upon the application through a process-based execution flow, albeit no longer using CGI specifically, the application is no longer the server again. This allows systems to save on resources by killing off all instances of your application when no requests are happening, and, with respect to scalability, it gives the freedom to the system the ability to launch as many instances of your application as is required to handle the load when the requests start coming in. Hence, with the end of the application being the server under the adoption of said process-based model, the application became serverless. > I was dumbfounded by the term The marketers have certainly tried to usurp the term for other purposes. It seems just about everything is trying to be called "serverless" nowadays. Perhaps that is the source of your dumbfoundary? Then again, if you know what you are talking about then you know when marketers are blowing smoke, so...

by chubot 2y ago

Uehreka 2y ago

PaaS, Containerization and Serverless are different concepts. App Engine is PaaS: You provide your app to the service in a runnable form (maybe a container image, maybe not) and they spin up a dedicated server (or slice of a server) to run it continuously. Lambda is Serverless: You provide them a bit of code and a condition under which that code should run. They charge you only when that thing happens and the code runs. How they make that happen (deploy it to a bajillion servers? Only deploy it when it’s called?) are implementation details that are abstracted from the user/developer as long as Lambda makes sure that the code runs whenever the condition happens. So with PaaS you have to pay even if you have 0 users, and when you scale up you have to do so by spinning up more “servers” (which may result in servers not being fully utilized). With Serverless you pay for the exact amount of compute you need, and 0 if your app is idle.

chubot 2y ago
> They charge you only when that thing happens and the code runs. That's how App Engine worked in 2008, and it looks like it still works that way: https://cloud.google.com/appengine/pricing https://cloud.google.com/appengine/pricing Apps running in the flexible environment are deployed to virtual machine types that you specify. These virtual machine resources are billed on a per-second basis with a 1 minute minimum usage cost. This applied to both the web workers and the batch workers It was "serverless" in 2008! > spin up a dedicated server (or slice of a server) to run it continuously. Absolutely NOT true of App Engine in 2008, and I'm pretty sure Heroku in 2008 too!
tantalor 2y ago
I recall you could configure app engine with maximum number of instances you wanted, but you definitely weren't charged if usage was 0. They would start the instances as needed. The fact that lambda would automatically scale to meet whatever QPS you got sounds terrifying.

randomdata 2y ago

> I was never quite sure why we got the name “serverless”, or where it came from Serverless refers to the software not being a server (usually implied to be a HTTP server), as was the common way to expose a network application throughout the 2010s, instead using some other process-based means to see the application interface with an outside server implementation. Hence server-less. It's not a new idea, of course. Good old CGI is serverless, but CGI defines a specific protocol whereas serverless refers to a broad category of various implementations.

bloppe 2y ago
Pedantry police here. I would define serverless to mean that all the hardware is completely abstracted away. For instance, on EC2, you have to pick an instance type. You pick how much memory and compute you need. On a managed kuberenetes cluster, you still have to think about nodes. On a serverless platform, though, you have no idea how many computers or what kinds of computers are actually running your code. It just runs when it needs to. Of course there's still an HTTP server somewhere, though. So, you could run a CGI script on a serverless platform, or a "serverful" one. You could even run it locally. https://en.wikipedia.org/wiki/Serverless_computing https://en.wikipedia.org/wiki/Serverless_computing Per wikipedia: "Serverless is a misnomer in the sense that servers are still used by cloud service providers to execute code for developers. However, developers of serverless applications are not concerned with capacity planning, configuration, management, maintenance, fault tolerance, or scaling of containers, virtual machines, or physical servers."
- randomdata 2y ago
  For all intents and purposes, when is the hardware not fully abstracted away? Even through the 2010s when running as a server was the norm, for the most part you could throw the same code onto basically any hardware without a second thought. But pedantically, serverless is to be taken literally. It implies that there is no server in your application.
  - bloppe 2y ago
    EC2 and managed kubernetes are two examples where you still have to think about hardware.

conradev 2y ago

Serverless, to me, is purely about efficiency. One way to measure that is the time for a "cold start" or "going from a state where you pay no money to one where you pay money". These gains in efficiency remove the need for over-provisioning and in many cases allow you to pass these savings onto the consumer (if you want to). Heroku is a few seconds: > It only takes a few seconds to start a one-off dyno process or to scale up a web or worker process. Lambda created Firecracker to be snappier: > The duration of a cold start varies from under 100 ms to over 1 second. I think App Engine is in the same ballpark as Lambda (and predated it). Fly.io uses Firecracker too: > While Fly Machine cold starts are extremely fast, it still takes a few hundred milliseconds, so it’s still worth weighing the impact it has on performance. but WASM is yet an order of magnitude faster and cheaper: > Cloudflare Workers has eliminated cold starts entirely, meaning they need zero spin up time. This is the case in every location in Cloudflare's global network. WASM is currently limited in what it can do, but if all you're doing is manipulating and serving HTML, it's fantastic at that.

dartos 2y ago

When lambda came out and serverless started getting big, most scrappy startups hired many frontend devs. It was the heydays of SPAs, light backends, and thick frontends. “Serverless” is a great way to say “you don’t need to be a backend dev or even know anything about backend to deploy with us” And it worked really really well. Then people realized that they should know a thing or two about backend. I always really hated that term.

friendzis 2y ago

Serverless is indeed a weird name if you know what you are talking about. I was dumbfounded by the term until I met people who actually thought of anything beyond pushing to git as "the server". Backend returns 4xx/5xx? The server is down. Particular data is not available in this instance and app handles this error path poorly? The server is down. There is no API to call for this, how do I implement "the server"? Some people still hold the worldview that application deployment is similar to mod-php where source files are yoloed to live filesytem. In this worldview, ignorant of complexities in operations, serverless is perfectly fitting marketing term, much like Autopilot, first chosen by Musk, chef's kiss.

randomdata 2y ago
> Serverless is indeed a weird name if you know what you are talking about. It is a perfectly logical name if you know what you are talking about and are familiar with the history of how these so-called serverless applications used to be developed. Which is to say that back in the day, once CGI fell out of fashion, the applications became servers themselves. You would have a listening HTTP server right within the application, often reverse proxied through something like Apache or nginx, and that is how it would be exposed to the world. The downside of this model is that your application always needs to be resident in order to serve requests, and, from a scaling perspective, you need to predict ahead of time many server instances are needed to handle the request load. This often resulted in poor resource utilization. Now with a return to back to the CGI-esq model, where you have managing servers call upon the application through a process-based execution flow, albeit no longer using CGI specifically, the application is no longer the server again. This allows systems to save on resources by killing off all instances of your application when no requests are happening, and, with respect to scalability, it gives the freedom to the system the ability to launch as many instances of your application as is required to handle the load when the requests start coming in. Hence, with the end of the application being the server under the adoption of said process-based model, the application became serverless. > I was dumbfounded by the term The marketers have certainly tried to usurp the term for other purposes. It seems just about everything is trying to be called "serverless" nowadays. Perhaps that is the source of your dumbfoundary? Then again, if you know what you are talking about then you know when marketers are blowing smoke, so...