11 ms·

How is owning an AWS account easier than a cheap dedicates server? You should have a code repo and backups in either case. At least some people mention "but I

How is owning an AWS account easier than a cheap dedicates server? You should have a code repo and backups in either case. At least some people mention "but I can scale this lambda x1000" and that's one advantage... But you can do all those tasks on a hetzner server in same amount of type, just python scripts.

justinram11 6y ago
Mostly it's about the maintenance costs of owning and managing a server -- on Lambda most of these tools are "set and forget". I don't want to have to manage security updates, disk usage, or any of the other multiple things that come with owning a server. I also could probably debate on the friendly-ness of just dumping all of these one-off services onto a single server (seems like it could get messy pretty quick), but I think you could probably go either way on that. We are also an AWS shop for our "production" stack already, so there is no added overhead for owning an AWS account.
- chillfox 6y ago
  Servers can also be "set and forget", just enable automatic patching
mark242 6y ago
Because that "cheap dedicated server" isn't all that cheap. Just the documentation for backups on your Hetzner server is ridiculous. Why, in the 21st century, should I as an application developer ever have to worry about that? Let's say that Hetzner server goes completely toast at 2am and you get a pingdom message. You log in, realize you have to restore from backup. You fire up a new instance, and go through your restore procedure, and everything works great. You're lucky to be offline for an hour. I cannot even tell you what would happen if an underlying instance running a Lambda goes offline, because it never happens. But let's say that an underlying machine dies in us-east-1. Lambda just starts running more instances of your code on another underlying group of cpus, and you aren't offline.
- crehn 6y ago
  And I’d argue the mere possibility of the server breaking at any time contributes to non-negligible amounts of sustained psychological stress.
  - mark242 6y ago
    Yes, this exactly. The fact that I can guarantee that my code is running, and have entire massive teams at Amazon whose literal job title is to keep my code running, it is such a freeing feeling. I might be able to delete rows from Dynamo from my code messing up, but Dynamo will never go offline.
    - crehn 6y ago
      The psychological effects of technology seem often overlooked—and they’re hard to quantify. I wish there was some easier way to quantify the “soft” aspects of everything that surrounds us, e.g. the long-term impact of beautiful and usable UI design, the reduction in “ambient” psychological stress, the impacts of chaos/consistency on how we feel, any robust measures of happiness, excitement, relaxation, etc. They seem to be such important attributes, but not as easily measured as a latency. Which in turn makes reaching consensus harder—and probably why design by committee doesn't work?
      - spyspy 6y ago
        My joke around the office is some people optimize for latency, some for throughput, some for memory usage. I, however, optimize for sleep. My entire goal is for my services to never wake me up. And if they do it had better because I clearly messed up and am the sole human alive able to fix it.
        ethanwillis 6y ago
        I optimize for escape hatches. Because if everything is on fire I want the ability to be able to bail(fix it). There's no point in waking up when everything is blowing up if you don't have the access to fix the underlying issue. AWS doesn't actually guarantee 99.9% uptime. What they guarantee is they'll give you some company currency[1] if they can't meet or exceed 99.9% uptime. So the next time the ship is on fire, don't worry, stay asleep and your Amazon account manager will be by shortly with a thimble of water to throw on you :) [1] - https://aws.amazon.com/about-aws/whats-new/2019/03/aws-systems-manager-announces-service-level-agreement/ https://aws.amazon.com/about-aws/whats-new/2019/03/aws-syste...
konjin 6y ago
Because you need two servers. One to run the application. One to run the application while the first is being upgraded. Now you need three servers, one to run the application, one as backup and one as load balancer. 99.99% uptime means you can be down no more than an hour a year. Which is really easy to overshoot when you're dicking around with a dist upgrade on three linux boxes. So that's why you end up with a server farm starting from your one small server.
- akkartik 6y ago
  Notice that grandparent comment explicitly carved out production servers. If you can't tolerate downtime while you're being upgraded, you're production.
- franciscop 6y ago
  99.99% of the websites out there don't need 99.99% uptime (from a business point of view)
  - klodolph 6y ago
    Once you get to 99.9% uptime you’re still less than 1 hour per month. I used to run apps for companies at work and it was standard operating procedure to have two app servers + load balancer for upgrades. Drain a server, upgrade it, boot it, check that it works, let it accept traffic. Repeat once more. Done. It may be true that most businesses don’t need the uptime, but I’d say it’s usually easier to give them high availability rather than field complaints when some random user tries to look something up during a maintenance window.
    - vanviegen 6y ago
      But where does the data sit? Would you be using some fancy multi-master synchronous replication for that, or is there a database server behind it?
      - klodolph 6y ago
shotgunsparkle 6y ago
On the flip side, serverless can scale to 0. Makes it very cost effective for one off functions
- ethanwillis 6y ago
  It doesn't actually scale to 0. The scale to 0 argument is actually just accounting trickery. Servers are still waiting around burning cycles doing nothing waiting to run a serverless function. All that has changed is that Amazon has spread the cost of low utilization across all customers. Which gets baked into your cost as well.

justinram11 6y ago

Mostly it's about the maintenance costs of owning and managing a server -- on Lambda most of these tools are "set and forget". I don't want to have to manage security updates, disk usage, or any of the other multiple things that come with owning a server. I also could probably debate on the friendly-ness of just dumping all of these one-off services onto a single server (seems like it could get messy pretty quick), but I think you could probably go either way on that. We are also an AWS shop for our "production" stack already, so there is no added overhead for owning an AWS account.

chillfox 6y ago
Servers can also be "set and forget", just enable automatic patching

mark242 6y ago

Because that "cheap dedicated server" isn't all that cheap. Just the documentation for backups on your Hetzner server is ridiculous. Why, in the 21st century, should I as an application developer ever have to worry about that? Let's say that Hetzner server goes completely toast at 2am and you get a pingdom message. You log in, realize you have to restore from backup. You fire up a new instance, and go through your restore procedure, and everything works great. You're lucky to be offline for an hour. I cannot even tell you what would happen if an underlying instance running a Lambda goes offline, because it never happens. But let's say that an underlying machine dies in us-east-1. Lambda just starts running more instances of your code on another underlying group of cpus, and you aren't offline.

crehn 6y ago
And I’d argue the mere possibility of the server breaking at any time contributes to non-negligible amounts of sustained psychological stress.
- mark242 6y ago
  Yes, this exactly. The fact that I can guarantee that my code is running, and have entire massive teams at Amazon whose literal job title is to keep my code running, it is such a freeing feeling. I might be able to delete rows from Dynamo from my code messing up, but Dynamo will never go offline.
  - crehn 6y ago
    The psychological effects of technology seem often overlooked—and they’re hard to quantify. I wish there was some easier way to quantify the “soft” aspects of everything that surrounds us, e.g. the long-term impact of beautiful and usable UI design, the reduction in “ambient” psychological stress, the impacts of chaos/consistency on how we feel, any robust measures of happiness, excitement, relaxation, etc. They seem to be such important attributes, but not as easily measured as a latency. Which in turn makes reaching consensus harder—and probably why design by committee doesn't work?
    - spyspy 6y ago
      My joke around the office is some people optimize for latency, some for throughput, some for memory usage. I, however, optimize for sleep. My entire goal is for my services to never wake me up. And if they do it had better because I clearly messed up and am the sole human alive able to fix it.
      - ethanwillis 6y ago
        I optimize for escape hatches. Because if everything is on fire I want the ability to be able to bail(fix it). There's no point in waking up when everything is blowing up if you don't have the access to fix the underlying issue. AWS doesn't actually guarantee 99.9% uptime. What they guarantee is they'll give you some company currency[1] if they can't meet or exceed 99.9% uptime. So the next time the ship is on fire, don't worry, stay asleep and your Amazon account manager will be by shortly with a thimble of water to throw on you :) [1] - https://aws.amazon.com/about-aws/whats-new/2019/03/aws-systems-manager-announces-service-level-agreement/ https://aws.amazon.com/about-aws/whats-new/2019/03/aws-syste...

konjin 6y ago

Because you need two servers. One to run the application. One to run the application while the first is being upgraded. Now you need three servers, one to run the application, one as backup and one as load balancer. 99.99% uptime means you can be down no more than an hour a year. Which is really easy to overshoot when you're dicking around with a dist upgrade on three linux boxes. So that's why you end up with a server farm starting from your one small server.

akkartik 6y ago
Notice that grandparent comment explicitly carved out production servers. If you can't tolerate downtime while you're being upgraded, you're production.
franciscop 6y ago
99.99% of the websites out there don't need 99.99% uptime (from a business point of view)
- klodolph 6y ago
  Once you get to 99.9% uptime you’re still less than 1 hour per month. I used to run apps for companies at work and it was standard operating procedure to have two app servers + load balancer for upgrades. Drain a server, upgrade it, boot it, check that it works, let it accept traffic. Repeat once more. Done. It may be true that most businesses don’t need the uptime, but I’d say it’s usually easier to give them high availability rather than field complaints when some random user tries to look something up during a maintenance window.
  - vanviegen 6y ago
    But where does the data sit? Would you be using some fancy multi-master synchronous replication for that, or is there a database server behind it?
    - klodolph 6y ago

shotgunsparkle 6y ago

On the flip side, serverless can scale to 0. Makes it very cost effective for one off functions

ethanwillis 6y ago
It doesn't actually scale to 0. The scale to 0 argument is actually just accounting trickery. Servers are still waiting around burning cycles doing nothing waiting to run a serverless function. All that has changed is that Amazon has spread the cost of low utilization across all customers. Which gets baked into your cost as well.