5 ms·

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).
jackpeterfletch 8y ago
It isnt more expensive! Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. Not only would it cost more but you'd probably hit the concurrency limit in AWS Lambda. But we also have an admin UI that gets about 2500 visits a day. We're running that for about $4 a month - with virtually no operational burden whatsoever, and with a reassurance of resilience. We worked out that the inflection point of value is at about 3 million requests a month. (that's an fag packet estimate, arbitrarily expensive 'request', your mileage may vary). Its no silver bullet, but for some applications, particularly personal projects, low traffic and startup scenarios it can be ideal.
- dullgiulio 8y ago
  I just hate it that discussions end up in people talking about keeping the function warm and quickly go downhill from there. A managed app runtime can be great though: for those who tried Google AppEngine back in the day, it was amazing to work with.
- 0x445442 8y ago
  >> Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. I'm curious about this statement because I'm currently working on a project where the intent is to port a legacy app to AWS Lambda. The legacy app is currently distributed across 96 VMs and handles ~ 50K reqs/min during normal times but can run into ~ 3M reqs/min during high demand. Are you saying AWS Lambda can not scale to handle this type of demand and if so can you point me to some resources/references that explain this? For the record, I'm not the one that came up with the architecture.
  - mcrittenden 8y ago
    I think he/she meant that Lambda wouldn't compete on pricing (as opposed to on performance).
    - geerlingguy 8y ago
      Both pricing and performance. It will scale, but it’s gonna cost a ton, and won’t be faster than running servers (and could be considerably slower for a percentage of requests).

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

jackpeterfletch 8y ago

It isnt more expensive! Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. Not only would it cost more but you'd probably hit the concurrency limit in AWS Lambda. But we also have an admin UI that gets about 2500 visits a day. We're running that for about $4 a month - with virtually no operational burden whatsoever, and with a reassurance of resilience. We worked out that the inflection point of value is at about 3 million requests a month. (that's an fag packet estimate, arbitrarily expensive 'request', your mileage may vary). Its no silver bullet, but for some applications, particularly personal projects, low traffic and startup scenarios it can be ideal.

dullgiulio 8y ago
I just hate it that discussions end up in people talking about keeping the function warm and quickly go downhill from there. A managed app runtime can be great though: for those who tried Google AppEngine back in the day, it was amazing to work with.
0x445442 8y ago
>> Our main path business path gets about 60,000 reqs min. For that, sure AWS Lambda would never compete. I'm curious about this statement because I'm currently working on a project where the intent is to port a legacy app to AWS Lambda. The legacy app is currently distributed across 96 VMs and handles ~ 50K reqs/min during normal times but can run into ~ 3M reqs/min during high demand. Are you saying AWS Lambda can not scale to handle this type of demand and if so can you point me to some resources/references that explain this? For the record, I'm not the one that came up with the architecture.
- mcrittenden 8y ago
  I think he/she meant that Lambda wouldn't compete on pricing (as opposed to on performance).
  - geerlingguy 8y ago
    Both pricing and performance. It will scale, but it’s gonna cost a ton, and won’t be faster than running servers (and could be considerably slower for a percentage of requests).