9 ms·

Can someone explain me what that hype about serverless is? As I understand it, serverless is just good old webhosting, but in the cloud. With webhosting I mean

Can someone explain me what that hype about serverless is? As I understand it, serverless is just good old webhosting, but in the cloud. With webhosting I mean providers offering a LAMP-environment and customer just upload their code and don't manage anything else. Is this correct? Then how is serverless different to this?

napo 8y ago
With serverless you only pay for a request and you (almost) don't care about scaling. While non-serverless implies that you have to manage how many server instances you want, and have them running and pay for them even if you have no traffic.
- seanwilson 8y ago
  Also, you don't need to worry about server security or server setup outside of the code you're running. With a typical VPS, you'd have to install software updates yourself and have a plan for how to set up a server from scratch again if needed (nontrivial if you do a lot of setup manually over SSH). Essentially, a good way to set something up that requires minimal maintenance.
  - icebraining 8y ago
    They were talking about Webhosting, not VPSs. With webhosting, the hosting company usually manages the software, you just dump your code (or cgi-bin binary) into a directory. For example https://www.hostgator.com/web-hosting https://www.hostgator.com/web-hosting
- nightfly 8y ago
  Just like old shared webhosting :)
  - icebraining 8y ago
    Most webhosting plans are fixed monthly fees, AFAIK. The only one I knew that billed for used resources was NearlyFreeSpeech.
    - blacksmith_tb 8y ago
      Was? [1] 1: https://www.nearlyfreespeech.net/services/pricing https://www.nearlyfreespeech.net/services/pricing
      - icebraining 8y ago
        Was, at the time I last looked at it :)
  - shaunpud 8y ago
    I made a quick list[0] of cheap shared hosting providers I found on LEB[1] [0] https://gist.github.com/shaunpud/35f77b542eaec7c7024bbb15c2e9f2e8 https://gist.github.com/shaunpud/35f77b542eaec7c7024bbb15c2e... [1] https://lowendbox.com https://lowendbox.com
- titanix2 8y ago
  I feel the whole "not paying for underused server" argument is pointless when a serverless solution is way more expensive than paying for an idle server.
  - ddorian43 8y ago
    But it's so much cheaper bud (it's not). It maybe is only when you're doing <= $10/month.
    - mickael-kerjean 8y ago
      I don't know if it's the HN effect but I never had a scaling problem. Prior acquisition the story says whatsapp used to run on a single server
      - ddorian43 8y ago
        It depends on the type of application. But when at 5pm your traffic grows by 200x (hint: it doesn't) and you petascale your aws vps megafleet (hint: you don't, especially your database you don't) then you are on route to unicorn-scale hypergrouth cash-money-team-happiness.
        tracker1 8y ago
        My personal take is this... 1. start with docker (or dokku), on a single server, it's easy enough to get going, automate CI/CD. Make sure your backups are working and relatively frequent. 2. Break your lower environments on to a separate server. 3. Break out your database, and set up redundancy at that layer. Leverage DBaaS if you can. 4. Grow to multiple app/api instances for redundancy, and setup rolling deployments. 5. Scale Vertically (bigger servers/instances) 6. Migrate to Kubernetes and expand your automation and tooling. 7. Break apart your application into smaller pieces to scale individually. Possibly leveraging platform tools like Lambda/Functions. 8. Work towards redundant datacenter and application data sharding to deliver a closer experience. By the time you get to 5-6, you should be making money or have a good investor strategy in place for capital. There's very little need to go all out when at concept or earlier release stages. 6-8 may take place in a different order, depending on your needs.. but again, you should have money or have raised capital by this point, or you have a relatively good problem to have otherwise. IIRC Stack Overflow grew vertically pretty big on a single server, then two (db/application split).
antocv 8y ago
People abuse the term serverless, yes to mean "cloud" or "somebody else server" and "just write the function you want we will find a server to run it on and report to you the result". The term I like to associate with serverless is all peer-to-peer, not client-server architecture, for example any datwebsite, on datproject, and any zsite on zeronet. There you dont have a server, really, a zite is a peer in a torrent swarm like any other, and can be found like any other torrent by its infohash (sha1) in the DHT, and can at any time go offline, while the swarm continues as nothing happened, new people can still access the zite from peers - and the zite despite rendering in a web-browser, can/should not really talk to any server, only to a peer-to-peer network. There is no "form submit" allowed on a zite, then it defeats the purpose of zeronet and similar techniques. Another example is gun.js
- shabda 8y ago
  You are coming up with your ow definition of serverless. For most people serverless means 1. Per invocation billing 2. No need to provision resources ahead of time Taking AWS's example 1. EC2 is not serverless but Lambda is 2. RDS is not serverless but Aurora Serverless is.
  - TomMarius 8y ago
    It's not their own definition, this was the default definition just a few years ago.
    - runn1ng 8y ago
      People started to use the term for something else and now it became the main meaning. "Serverless" is nowadays "AWS Lambda" (and similar products). I wish people called it FaaS (function as a service), but they call it "serverless", and it's fine I guess
      - antocv 8y ago
        Yeah, now the term is an oxymoron, "serverless" but there is a server and a client.
TeMPOraL 8y ago
It does feel like just FTPing a .php file into your LAMP webhost, but with autoscaling, slicker UX and much more vendor lock-in.
- jedberg 8y ago
  > and much more vendor lock-in. This is a myth that really needs to be busted. There is almost no lock in with serverless. The serverless products from all the major providers are nearly identical. The lock in comes from the services you are using within a particular cloud, which you can avoid if you want to by running everything else in k8s.
  - karolist 8y ago
    regarding your k8s comment, did you mean kubeless?
    - sethammons 8y ago
      k8s == kubernetes, like i18n == internationalization
- Cthulhu_ 8y ago
  With the difference that you pay per request instead of per month / year. Mind you, given how cheap LAMP webhosts can be, I'm fairly sure they would be cheaper if you don't need the autoscaling.
  - bufferoverflow 8y ago
    Seriously, VPS hosts are so far ahead of the cloud when it comes to cost/resource ratio. I can get a 4-core 4GB 120GB SHDD instance for ~$2/month. https://lowendbox.com/blog/hostedsimply-4gb-ram-ssd-cached-vps-w-120gb-hdd-for-25-yr-in-los-angeles-new-york/ https://lowendbox.com/blog/hostedsimply-4gb-ram-ssd-cached-v... EDIT: cheaper even, $1.58/month: https://lowendbox.com/blog/n3servers-vps-hosting-and-hybrid-dedicated-servers-in-new-york-1gb-vps-9-49-yr-more/ https://lowendbox.com/blog/n3servers-vps-hosting-and-hybrid-...
deleted 8y ago
[deleted]
rkangel 8y ago
To me, it's about the abstraction layer that you interact with when bringing up your stack. That abstraction layer has gradually moved higher over time as providers try and deliver more for their customers: 1) Hardware) 'I want to run Linux + Stack + App'. You get an empty rack, a network port and a power socket. You have to buy iron, install and maintain OS/platform, runtime environment and your service. Scaling requires more work and buying more stuff. 2) VMs) 'I want to run Stack + App'. Machine and OS is provided for you and maintained. You still have to build runtime environment and your app. Scaling doesn't require capex like (1), but still slow - you have to decide how much capacity you want. 3) Containers) Still 'I want to run Stack + App' but faster scaling so can be responsive rather than in advance. A halfway step to: 4) Serverless) 'I want to run App'. Runtime environment, hosting etc is all taken care of. You just write the app and everything else works at the capacity you need. We've been aiming at this last level of abstraction for a while. As you pointed out, the classic VPS with LAMP got you some of the way there, but without the scaling advantages. Google App Engine got closer but was its own special world. Containers are an important technical enabler to doing it more portably.
- Huggernaut 8y ago
  I'd like to think 4) is actually Containerless or PaaS - "I want to run App". Serverless or FaaS takes this a step further to "I want to run App on demand". What do you think?
  - rkangel 8y ago
    I was going to write a point disagreeing with you, but the logic didn't work. The fact that the PaaS implementation used requires scaling in advance, vs FaaS which can scale as requests come in means that you are exposed to one more (important) detail with PaaS - number of instances. So yes, FaaS has gone up the abstraction stack one more step.
- y4mi 8y ago
  let me guess, you don't have any experience in ops? 1) Scaling doesn't really require more work. It needs a bigger investment because a hardware hypervisor costs significantly more than a vm... after all, that hard metal can host tens of VMs 2) you still need to manage your linux system and OS if you're buying a VM... the only thing you don't need to worry about is hardware. So, a faulty hard drive, hypervisor failover and similar stuff is taken care of. That doesn't mean that it works, however. It just means that somebody else will take care of it... though it might not work and you're entirely on their mercy to fix it 3) containers don't inherently give you better scaling either. creating images from VMs has been done for ages before docker was a thing, and provisioning a new Node from a VM Image is pretty easy if you're already using Terraform or similar. you're just able to utilize a higher percentage of your hardware with containers, as you don't need to virtualize the kernel... so its a cost-cutting issue, not scaling
m12k 8y ago
The way I see it, it's basically just a cost-saving measure. If you have some very varying workloads, instead of paying for having a bunch of servers running all the time (and idling most of that time), when you actually need the extra compute power you can let AWS Lambda spin up a server, run the code, then spin it down again. That's clever and all, and might save you a pretty penny if you have huge workloads only part of the time - but for most users, it's hardly worthy of the hype.
manigandham 8y ago
It's the new PaaS, but scoped down to a smaller payload of just a single function, although most platforms now let you upload an entire app or container anyway. The other big change was removing the concept of servers/instances altogether so there is no step-wise scaling at all that you can see or control.
prepend 8y ago
It’s kind of similar, but imagine php without the ability to break anybody else on the web host and infinite resources as much as you wish to pay. So no server migrations. No debugging performance problems. So it is just the natural progression of a shared LAMP host that’s worked well for 20 years.
mo1ok 8y ago
It just simplifies an entire field of software engineering (devops) into a simple "one-click" setup. Before, you had to open an account, provision a server, figure out your machine image, install dependencies, figure out error/process handling, deploy... ...figure out optimization, payment, RAM usage, longevity, how many instances do I need? What are peak hours, and should it autoscale? No you just run a single command line and it's up in the cloud, figuring all that out for you automatically.
robot 8y ago
https://medium.com/@bahadirbalban/what-is-serverless-and-what-is-a-lambda-fdb6dc8de223 https://medium.com/@bahadirbalban/what-is-serverless-and-wha...
jeremylikness 8y ago
Serverless is identical in every respect to traditional hosting/managed services with one exception: micro-billing. In web hosting you are often either constrained by the "level" you pay for, or have to configure scale and pay for the size of your domain. True serverless should auto-scale on demand without your intervention, and it should only bill you for what you use. Have a slow month and are idle? Pennies. Have a phenomenal month and huge usage? Dollars. There is less server, not no server, but instead of worrying about the OS or even platform level dependencies, you can focus just on the bit of code you want to run. If your server is a house and a virtual machine is like renting a house, platform-as-a-service is an apartment and serverless is a hotel (thanks to Scott Hanselman for that analogy).
headcanon 8y ago
To add to the other comments, using serverless with AWS Lambda has been very useful for us in our data pipeline, in a large part because you can hook them up to respond to a number of events like S3 uploads, updates to dynamo tables, or to an SNS or message queue topic. It scales up effortlessly and is very cheap to run. Could we have done this by avoiding serverless? sure but we would have to maintain quite a bit more infrastructure - why do that when someone else can handle that infrastructure cheaply? I realize my example is provider-specific but I think having them act as asynchronous data transforms and workflows are where the serverless really shines, especially given the invocation overhead of 20-30ms or so when hot, and several seconds when cold. We have run into instances where the serverless model doesn't work so well, like when we updated our graphql API to query a postgres store - each lambda invocation created its own connection pool and would overload the database. Currently theres no way to reliably persist those somewhere else and have the lambdas pick up the persistent connection (like how a redis session store would work) - perhaps that will change. the lambdas work best when they're more-or-less "pure functions", so if you have to keep things like sql connection pools, or a session around, you still need your own persistent server.

napo 8y ago

With serverless you only pay for a request and you (almost) don't care about scaling. While non-serverless implies that you have to manage how many server instances you want, and have them running and pay for them even if you have no traffic.

seanwilson 8y ago
Also, you don't need to worry about server security or server setup outside of the code you're running. With a typical VPS, you'd have to install software updates yourself and have a plan for how to set up a server from scratch again if needed (nontrivial if you do a lot of setup manually over SSH). Essentially, a good way to set something up that requires minimal maintenance.
- icebraining 8y ago
  They were talking about Webhosting, not VPSs. With webhosting, the hosting company usually manages the software, you just dump your code (or cgi-bin binary) into a directory. For example https://www.hostgator.com/web-hosting https://www.hostgator.com/web-hosting
nightfly 8y ago
Just like old shared webhosting :)
- icebraining 8y ago
  Most webhosting plans are fixed monthly fees, AFAIK. The only one I knew that billed for used resources was NearlyFreeSpeech.
  - blacksmith_tb 8y ago
    Was? [1] 1: https://www.nearlyfreespeech.net/services/pricing https://www.nearlyfreespeech.net/services/pricing
    - icebraining 8y ago
      Was, at the time I last looked at it :)
- shaunpud 8y ago
  I made a quick list[0] of cheap shared hosting providers I found on LEB[1] [0] https://gist.github.com/shaunpud/35f77b542eaec7c7024bbb15c2e9f2e8 https://gist.github.com/shaunpud/35f77b542eaec7c7024bbb15c2e... [1] https://lowendbox.com https://lowendbox.com
titanix2 8y ago
I feel the whole "not paying for underused server" argument is pointless when a serverless solution is way more expensive than paying for an idle server.
- ddorian43 8y ago
  But it's so much cheaper bud (it's not). It maybe is only when you're doing <= $10/month.
  - mickael-kerjean 8y ago
    I don't know if it's the HN effect but I never had a scaling problem. Prior acquisition the story says whatsapp used to run on a single server
    - ddorian43 8y ago
      It depends on the type of application. But when at 5pm your traffic grows by 200x (hint: it doesn't) and you petascale your aws vps megafleet (hint: you don't, especially your database you don't) then you are on route to unicorn-scale hypergrouth cash-money-team-happiness.
      - tracker1 8y ago
        My personal take is this... 1. start with docker (or dokku), on a single server, it's easy enough to get going, automate CI/CD. Make sure your backups are working and relatively frequent. 2. Break your lower environments on to a separate server. 3. Break out your database, and set up redundancy at that layer. Leverage DBaaS if you can. 4. Grow to multiple app/api instances for redundancy, and setup rolling deployments. 5. Scale Vertically (bigger servers/instances) 6. Migrate to Kubernetes and expand your automation and tooling. 7. Break apart your application into smaller pieces to scale individually. Possibly leveraging platform tools like Lambda/Functions. 8. Work towards redundant datacenter and application data sharding to deliver a closer experience. By the time you get to 5-6, you should be making money or have a good investor strategy in place for capital. There's very little need to go all out when at concept or earlier release stages. 6-8 may take place in a different order, depending on your needs.. but again, you should have money or have raised capital by this point, or you have a relatively good problem to have otherwise. IIRC Stack Overflow grew vertically pretty big on a single server, then two (db/application split).

antocv 8y ago

People abuse the term serverless, yes to mean "cloud" or "somebody else server" and "just write the function you want we will find a server to run it on and report to you the result". The term I like to associate with serverless is all peer-to-peer, not client-server architecture, for example any datwebsite, on datproject, and any zsite on zeronet. There you dont have a server, really, a zite is a peer in a torrent swarm like any other, and can be found like any other torrent by its infohash (sha1) in the DHT, and can at any time go offline, while the swarm continues as nothing happened, new people can still access the zite from peers - and the zite despite rendering in a web-browser, can/should not really talk to any server, only to a peer-to-peer network. There is no "form submit" allowed on a zite, then it defeats the purpose of zeronet and similar techniques. Another example is gun.js

shabda 8y ago
You are coming up with your ow definition of serverless. For most people serverless means 1. Per invocation billing 2. No need to provision resources ahead of time Taking AWS's example 1. EC2 is not serverless but Lambda is 2. RDS is not serverless but Aurora Serverless is.
- TomMarius 8y ago
  It's not their own definition, this was the default definition just a few years ago.
  - runn1ng 8y ago
    People started to use the term for something else and now it became the main meaning. "Serverless" is nowadays "AWS Lambda" (and similar products). I wish people called it FaaS (function as a service), but they call it "serverless", and it's fine I guess
    - antocv 8y ago
      Yeah, now the term is an oxymoron, "serverless" but there is a server and a client.

TeMPOraL 8y ago

It does feel like just FTPing a .php file into your LAMP webhost, but with autoscaling, slicker UX and much more vendor lock-in.

jedberg 8y ago
> and much more vendor lock-in. This is a myth that really needs to be busted. There is almost no lock in with serverless. The serverless products from all the major providers are nearly identical. The lock in comes from the services you are using within a particular cloud, which you can avoid if you want to by running everything else in k8s.
- karolist 8y ago
  regarding your k8s comment, did you mean kubeless?
  - sethammons 8y ago
    k8s == kubernetes, like i18n == internationalization
Cthulhu_ 8y ago
With the difference that you pay per request instead of per month / year. Mind you, given how cheap LAMP webhosts can be, I'm fairly sure they would be cheaper if you don't need the autoscaling.
- bufferoverflow 8y ago
  Seriously, VPS hosts are so far ahead of the cloud when it comes to cost/resource ratio. I can get a 4-core 4GB 120GB SHDD instance for ~$2/month. https://lowendbox.com/blog/hostedsimply-4gb-ram-ssd-cached-vps-w-120gb-hdd-for-25-yr-in-los-angeles-new-york/ https://lowendbox.com/blog/hostedsimply-4gb-ram-ssd-cached-v... EDIT: cheaper even, $1.58/month: https://lowendbox.com/blog/n3servers-vps-hosting-and-hybrid-dedicated-servers-in-new-york-1gb-vps-9-49-yr-more/ https://lowendbox.com/blog/n3servers-vps-hosting-and-hybrid-...

deleted 8y ago

[deleted]

rkangel 8y ago

To me, it's about the abstraction layer that you interact with when bringing up your stack. That abstraction layer has gradually moved higher over time as providers try and deliver more for their customers: 1) Hardware) 'I want to run Linux + Stack + App'. You get an empty rack, a network port and a power socket. You have to buy iron, install and maintain OS/platform, runtime environment and your service. Scaling requires more work and buying more stuff. 2) VMs) 'I want to run Stack + App'. Machine and OS is provided for you and maintained. You still have to build runtime environment and your app. Scaling doesn't require capex like (1), but still slow - you have to decide how much capacity you want. 3) Containers) Still 'I want to run Stack + App' but faster scaling so can be responsive rather than in advance. A halfway step to: 4) Serverless) 'I want to run App'. Runtime environment, hosting etc is all taken care of. You just write the app and everything else works at the capacity you need. We've been aiming at this last level of abstraction for a while. As you pointed out, the classic VPS with LAMP got you some of the way there, but without the scaling advantages. Google App Engine got closer but was its own special world. Containers are an important technical enabler to doing it more portably.

Huggernaut 8y ago
I'd like to think 4) is actually Containerless or PaaS - "I want to run App". Serverless or FaaS takes this a step further to "I want to run App on demand". What do you think?
- rkangel 8y ago
  I was going to write a point disagreeing with you, but the logic didn't work. The fact that the PaaS implementation used requires scaling in advance, vs FaaS which can scale as requests come in means that you are exposed to one more (important) detail with PaaS - number of instances. So yes, FaaS has gone up the abstraction stack one more step.
y4mi 8y ago
let me guess, you don't have any experience in ops? 1) Scaling doesn't really require more work. It needs a bigger investment because a hardware hypervisor costs significantly more than a vm... after all, that hard metal can host tens of VMs 2) you still need to manage your linux system and OS if you're buying a VM... the only thing you don't need to worry about is hardware. So, a faulty hard drive, hypervisor failover and similar stuff is taken care of. That doesn't mean that it works, however. It just means that somebody else will take care of it... though it might not work and you're entirely on their mercy to fix it 3) containers don't inherently give you better scaling either. creating images from VMs has been done for ages before docker was a thing, and provisioning a new Node from a VM Image is pretty easy if you're already using Terraform or similar. you're just able to utilize a higher percentage of your hardware with containers, as you don't need to virtualize the kernel... so its a cost-cutting issue, not scaling

m12k 8y ago

The way I see it, it's basically just a cost-saving measure. If you have some very varying workloads, instead of paying for having a bunch of servers running all the time (and idling most of that time), when you actually need the extra compute power you can let AWS Lambda spin up a server, run the code, then spin it down again. That's clever and all, and might save you a pretty penny if you have huge workloads only part of the time - but for most users, it's hardly worthy of the hype.

manigandham 8y ago

It's the new PaaS, but scoped down to a smaller payload of just a single function, although most platforms now let you upload an entire app or container anyway. The other big change was removing the concept of servers/instances altogether so there is no step-wise scaling at all that you can see or control.

prepend 8y ago

It’s kind of similar, but imagine php without the ability to break anybody else on the web host and infinite resources as much as you wish to pay. So no server migrations. No debugging performance problems. So it is just the natural progression of a shared LAMP host that’s worked well for 20 years.

mo1ok 8y ago

It just simplifies an entire field of software engineering (devops) into a simple "one-click" setup. Before, you had to open an account, provision a server, figure out your machine image, install dependencies, figure out error/process handling, deploy... ...figure out optimization, payment, RAM usage, longevity, how many instances do I need? What are peak hours, and should it autoscale? No you just run a single command line and it's up in the cloud, figuring all that out for you automatically.

robot 8y ago

https://medium.com/@bahadirbalban/what-is-serverless-and-what-is-a-lambda-fdb6dc8de223 https://medium.com/@bahadirbalban/what-is-serverless-and-wha...

jeremylikness 8y ago

Serverless is identical in every respect to traditional hosting/managed services with one exception: micro-billing. In web hosting you are often either constrained by the "level" you pay for, or have to configure scale and pay for the size of your domain. True serverless should auto-scale on demand without your intervention, and it should only bill you for what you use. Have a slow month and are idle? Pennies. Have a phenomenal month and huge usage? Dollars. There is less server, not no server, but instead of worrying about the OS or even platform level dependencies, you can focus just on the bit of code you want to run. If your server is a house and a virtual machine is like renting a house, platform-as-a-service is an apartment and serverless is a hotel (thanks to Scott Hanselman for that analogy).

headcanon 8y ago

To add to the other comments, using serverless with AWS Lambda has been very useful for us in our data pipeline, in a large part because you can hook them up to respond to a number of events like S3 uploads, updates to dynamo tables, or to an SNS or message queue topic. It scales up effortlessly and is very cheap to run. Could we have done this by avoiding serverless? sure but we would have to maintain quite a bit more infrastructure - why do that when someone else can handle that infrastructure cheaply? I realize my example is provider-specific but I think having them act as asynchronous data transforms and workflows are where the serverless really shines, especially given the invocation overhead of 20-30ms or so when hot, and several seconds when cold. We have run into instances where the serverless model doesn't work so well, like when we updated our graphql API to query a postgres store - each lambda invocation created its own connection pool and would overload the database. Currently theres no way to reliably persist those somewhere else and have the lambdas pick up the persistent connection (like how a redis session store would work) - perhaps that will change. the lambdas work best when they're more-or-less "pure functions", so if you have to keep things like sql connection pools, or a session around, you still need your own persistent server.