6 ms·

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 insta

by 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).

by napo 8y ago

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).