3 ms·

The percentage is kind of irrelevant. The issue is that if you're running something like an e-commerce site and any percentage of people can't hit your site bec

The percentage is kind of irrelevant. The issue is that if you're running something like an e-commerce site and any percentage of people can't hit your site because of a TTL issue with one of your down servers, you're likely to never know how much lost revenue you've had. Site is down, go to another store to buy what you need. You also have no control over fixing the issue, other than to get the server back and running. This has downstream effects, how do you cycle the server for upgrades or maintenance? I don't understand why anyone would argue for this as a solution when there are near zero effort better ways of doing this that don't have any of the negative downsides.

zamadatix 2y ago
Why should OpenFreeMapbuild, a free public service with no SLAs, build their solutions based on what's optimal for an e-commerce site to retain customer instead of what's optimal for their project's needs? Some clients can afford to lose connectivity during an active outage, not everyone is the worst case. My web service using round-robin DNS is not an ecommerce site either, the users have already paid by the time they are using it and none have ever filed a ticket or noted a complaint in the service review about the failover being slow or unreliable so why should I build it different just because some other use case could theoretically be losing a customer during an active outage? Running load balancers does have a downside, every single design choice other than "don't do anything" is another point of configuration and cost. Round-robin based DNS solutions often require nothing more than adding a second A record and are possible the simplest solution to many problems for that reason. Many cloud DNS systems offer automatic pullout functionality if that's even a need, keeping cases where pullout is a must still not needing to move to more complex answers. Solutions only make sense in context of what service one is delivering, not in what thinks sounds sexiest, what is the absolute best, or what could be a possible problem in some other use case. That you can think of a case it could possibly not work out is not the same thing as an example of why it's a bad design for everyone - or even that scenario. If you can't gather data the answer is to find a way to do so and make a data driven decision, not swag based on personal opinion. Not every app is only correctly scoped when resources are put in to make it a fluid 144 FPS native experience in <1 MB package, not every DC needs 2n redundancy to be up enough for its customers, not every database needs to be designed to scale to a billion users, and not every web service needs a load balancer to be reliable enough for the use case.
- latchkey 2y ago
  If your use case is so inconsequential as to not have any sort of negative impacts from outages, you don't need round robin dns. You just have one IP address and you're done. That is truly the simplest solution here. If you get to the point of needing what you think RRD is providing you, then you might as well do it using a solution that doesn't have the negative side effects of RRD. If you are going as far as using a cloud dns system with "automatic pullout", then you might as well just use a cloud dns, like CF, that solves the round robin dns known issues for you.
  - zamadatix 2y ago
    > If your use case is so inconsequential as to not have any sort of negative impacts from outages, you don't need round robin dns. You just have one IP address and you're done. That is truly the simplest solution here. An example of a time failover needs to be instant or failover doesn't matter at all is completely unrelated to whether or not there are times "somewhat decent" failover is needed. Not to mention times load balancing primary role may be to balance the load rather than boost redundancy. As my personal example: waiting a seconds (or a couple minutes in the absolute worst case) to reconnect to a web terminal session in the occasional failover is not an impacting issue, waiting for someone to troubleshoot and diagnose a single server outage (a couple of minutes to many hours in the worst case) is an event worthy of handing out free vouchers to do the training another time. We've never had to do the latter due to remote training infrastructure failover issues in many years without a traditional load balancer (despite many outages) and it's allowed the training infrastructure to be extremely lightly staffed. As the example from the blog: waiting seconds (or a couple minutes in the absolute worst case) for free map tiles to load in the occasional failover is probably preferable when weighed against things spending limited money on load balancers vs additional servers for all-round performance and scalability (tying back to the "balance the load" use case being the bigger value per dollar). > If you are going as far as using a cloud dns system with "automatic pullout", then you might as well just use a cloud dns, like CF, that solves the round robin dns known issues for you. Not sure what you mean here, CF's cloud dns is indeed one example of what I meant by a cloud dns system with "automatic pullout". It's referenced in the article, Zero Downtime Failover. Perhaps you meant to say "why not just use Cloudflare Load Balancing at that point" instead? The answer to that, if it were the question, is it's a paid addon ("Running load balancers does have a downside") as mentioned in the article. If that wasn't the intended question, then yes - you've got it, though I'm not sure how it's "might as well" rather than exactly what was said to use. If I had to guess (and I could be very wrong) you come more from a background on the for profit high end datacenter hosted services side. Large scale, high performance, bleeding edge services for high dollar, 2n redundancy, high dollar equipment support contracts, the idea of not having cold spares on site for things with n+2 (or more) hot redundancy unthinkable given the target SLAs shouldn't allow waiting for equipment to show up until redundancy levels are back. That's fine and dandy. It's a fun type of environment and comes with certain assumptions... but trying to apply the common sense logic you'd use in those kinds of scenarios like "just assume you need full load balancers if you're going to make any uptime guarantee at all" doesn't necessarily apply to everyone else in all other scenarios. That's why engineering starts with asking more about what in the use case drives that decision rather than declaring a solution universally wrong out of the gate.

zamadatix 2y ago

Why should OpenFreeMapbuild, a free public service with no SLAs, build their solutions based on what's optimal for an e-commerce site to retain customer instead of what's optimal for their project's needs? Some clients can afford to lose connectivity during an active outage, not everyone is the worst case. My web service using round-robin DNS is not an ecommerce site either, the users have already paid by the time they are using it and none have ever filed a ticket or noted a complaint in the service review about the failover being slow or unreliable so why should I build it different just because some other use case could theoretically be losing a customer during an active outage? Running load balancers does have a downside, every single design choice other than "don't do anything" is another point of configuration and cost. Round-robin based DNS solutions often require nothing more than adding a second A record and are possible the simplest solution to many problems for that reason. Many cloud DNS systems offer automatic pullout functionality if that's even a need, keeping cases where pullout is a must still not needing to move to more complex answers. Solutions only make sense in context of what service one is delivering, not in what thinks sounds sexiest, what is the absolute best, or what could be a possible problem in some other use case. That you can think of a case it could possibly not work out is not the same thing as an example of why it's a bad design for everyone - or even that scenario. If you can't gather data the answer is to find a way to do so and make a data driven decision, not swag based on personal opinion. Not every app is only correctly scoped when resources are put in to make it a fluid 144 FPS native experience in <1 MB package, not every DC needs 2n redundancy to be up enough for its customers, not every database needs to be designed to scale to a billion users, and not every web service needs a load balancer to be reliable enough for the use case.

latchkey 2y ago
If your use case is so inconsequential as to not have any sort of negative impacts from outages, you don't need round robin dns. You just have one IP address and you're done. That is truly the simplest solution here. If you get to the point of needing what you think RRD is providing you, then you might as well do it using a solution that doesn't have the negative side effects of RRD. If you are going as far as using a cloud dns system with "automatic pullout", then you might as well just use a cloud dns, like CF, that solves the round robin dns known issues for you.
- zamadatix 2y ago
  > If your use case is so inconsequential as to not have any sort of negative impacts from outages, you don't need round robin dns. You just have one IP address and you're done. That is truly the simplest solution here. An example of a time failover needs to be instant or failover doesn't matter at all is completely unrelated to whether or not there are times "somewhat decent" failover is needed. Not to mention times load balancing primary role may be to balance the load rather than boost redundancy. As my personal example: waiting a seconds (or a couple minutes in the absolute worst case) to reconnect to a web terminal session in the occasional failover is not an impacting issue, waiting for someone to troubleshoot and diagnose a single server outage (a couple of minutes to many hours in the worst case) is an event worthy of handing out free vouchers to do the training another time. We've never had to do the latter due to remote training infrastructure failover issues in many years without a traditional load balancer (despite many outages) and it's allowed the training infrastructure to be extremely lightly staffed. As the example from the blog: waiting seconds (or a couple minutes in the absolute worst case) for free map tiles to load in the occasional failover is probably preferable when weighed against things spending limited money on load balancers vs additional servers for all-round performance and scalability (tying back to the "balance the load" use case being the bigger value per dollar). > If you are going as far as using a cloud dns system with "automatic pullout", then you might as well just use a cloud dns, like CF, that solves the round robin dns known issues for you. Not sure what you mean here, CF's cloud dns is indeed one example of what I meant by a cloud dns system with "automatic pullout". It's referenced in the article, Zero Downtime Failover. Perhaps you meant to say "why not just use Cloudflare Load Balancing at that point" instead? The answer to that, if it were the question, is it's a paid addon ("Running load balancers does have a downside") as mentioned in the article. If that wasn't the intended question, then yes - you've got it, though I'm not sure how it's "might as well" rather than exactly what was said to use. If I had to guess (and I could be very wrong) you come more from a background on the for profit high end datacenter hosted services side. Large scale, high performance, bleeding edge services for high dollar, 2n redundancy, high dollar equipment support contracts, the idea of not having cold spares on site for things with n+2 (or more) hot redundancy unthinkable given the target SLAs shouldn't allow waiting for equipment to show up until redundancy levels are back. That's fine and dandy. It's a fun type of environment and comes with certain assumptions... but trying to apply the common sense logic you'd use in those kinds of scenarios like "just assume you need full load balancers if you're going to make any uptime guarantee at all" doesn't necessarily apply to everyone else in all other scenarios. That's why engineering starts with asking more about what in the use case drives that decision rather than declaring a solution universally wrong out of the gate.