3 ms·

I'm replying to the comment above. If the article picks a few clients and it happens to work, that is effectively "knowing your clients". At which point, it mea

I'm replying to the comment above. If the article picks a few clients and it happens to work, that is effectively "knowing your clients". At which point, it means you have control over the client/server relationship and if we are trying to simplify by not using load balancers, we might as well simplify things even further, and not use DNS. It is an absurd train of thought that nobody in their right mind would consider... just like using DNS-RR as a replacement for load balancing.

zamadatix 2y ago
I must be having trouble following your train of thought here - many large web services like Cloudflare and Akamai serve large volumes of content through round robin DNS balancing, what's absurd about their success? They certainly don't know every client that'll ever connect to a CDN on the internet... it just happens to work almost every time anyways. That very few clients might not instantly flip over isn't always a design failure worth deploying full load balancers. I'm also still not following why the decisions for whether or not you need a load balancer are supposed to be in any way equivalent to the decisions of when using DNS would make sense or not?
- latchkey 2y ago
  We are not talking about "large web services", we are talking about small end users spinning up their own DNS-RR "solution". LWS get away with it because of Anycast... https://www.cloudflare.com/en-gb/learning/cdn/glossary/anycast-network/ https://www.cloudflare.com/en-gb/learning/cdn/glossary/anyca...
  - zamadatix 2y ago
    Anycast is certainly a nice layer to add but it's not a requirement for DNS round robin to work reliably. It does save some of the concern around relying on selection of an efficiently close choice by the client though and can be a good option for failover. More directly - is there some set of common web client I've been missing for many years that just doesn't follow DNS TTLs or try alternate records? I think the article gets it right with the wish list at the end containing a Amazon Route 53-like "pull dead entries automatically" note but maybe I'm missing something else? I've used this approach (pull the dead server entries from DNS, wait for TTL) and never caught any unexpected failures during outages but maybe I haven't been looking in the right places? If you mean it's possible to design something with round-robin DNS in a way that more clients than you expect will fail then absolutely, you can do things the wrong way with most any solution. Sometimes you can be fine with a subset of clients not always working during an outage or you can be fine with a solution which provides slower failover than an active load balancer. What I'm trying to find is why round-robin DNS must always be the wrong answer in all design cases.
    - latchkey 2y ago
      > is there some set of common web client I've been missing for many years that just doesn't follow DNS TTLs or try alternate records? Yes. There are tons of people with outdated and/or buggy software still using the internet today.
      - zamadatix 2y ago
        What % did you find to be "tons" with these specific bugs? I'm assuming it was quite a significant number (at least 10%?) that broke badly quite often given the certainty it's the wrong decision for all solutions, any idea how to help me identify which clients I've been missing or might run into? DNS TTLs are also pretty necessary for most web systems to work reliably, regardless of load balancer or not, so what ways do you work around having large numbers of clients which don't obey them (beyond hoping to permanently occupy the same set of IPs for the life of the service of course)?
        latchkey 2y ago
        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.

zamadatix 2y ago

I must be having trouble following your train of thought here - many large web services like Cloudflare and Akamai serve large volumes of content through round robin DNS balancing, what's absurd about their success? They certainly don't know every client that'll ever connect to a CDN on the internet... it just happens to work almost every time anyways. That very few clients might not instantly flip over isn't always a design failure worth deploying full load balancers. I'm also still not following why the decisions for whether or not you need a load balancer are supposed to be in any way equivalent to the decisions of when using DNS would make sense or not?

latchkey 2y ago
We are not talking about "large web services", we are talking about small end users spinning up their own DNS-RR "solution". LWS get away with it because of Anycast... https://www.cloudflare.com/en-gb/learning/cdn/glossary/anycast-network/ https://www.cloudflare.com/en-gb/learning/cdn/glossary/anyca...
- zamadatix 2y ago
  Anycast is certainly a nice layer to add but it's not a requirement for DNS round robin to work reliably. It does save some of the concern around relying on selection of an efficiently close choice by the client though and can be a good option for failover. More directly - is there some set of common web client I've been missing for many years that just doesn't follow DNS TTLs or try alternate records? I think the article gets it right with the wish list at the end containing a Amazon Route 53-like "pull dead entries automatically" note but maybe I'm missing something else? I've used this approach (pull the dead server entries from DNS, wait for TTL) and never caught any unexpected failures during outages but maybe I haven't been looking in the right places? If you mean it's possible to design something with round-robin DNS in a way that more clients than you expect will fail then absolutely, you can do things the wrong way with most any solution. Sometimes you can be fine with a subset of clients not always working during an outage or you can be fine with a solution which provides slower failover than an active load balancer. What I'm trying to find is why round-robin DNS must always be the wrong answer in all design cases.
  - latchkey 2y ago
    > is there some set of common web client I've been missing for many years that just doesn't follow DNS TTLs or try alternate records? Yes. There are tons of people with outdated and/or buggy software still using the internet today.
    - zamadatix 2y ago
      What % did you find to be "tons" with these specific bugs? I'm assuming it was quite a significant number (at least 10%?) that broke badly quite often given the certainty it's the wrong decision for all solutions, any idea how to help me identify which clients I've been missing or might run into? DNS TTLs are also pretty necessary for most web systems to work reliably, regardless of load balancer or not, so what ways do you work around having large numbers of clients which don't obey them (beyond hoping to permanently occupy the same set of IPs for the life of the service of course)?
      - latchkey 2y ago
        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.