Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

When you spin more instances as load grows, what updates the DNS?

When you have more than one service interacting, or when your LB restarts / fails over, what updates the DNS?

Here's where service discovery enters the picture. It needs not be excessively complex.



> When you spin more instances as load grows, what updates the DNS?

If you're using cloud LBs, this happens automatically. If not, you can have the instances register themselves in DNS when they turn on. You can also have an out of band system register things in DNS based on rules (or maybe you already have software that supports registering based on health checks so you can add DNS entries from a fixed list of static IPs when they become healthy/powered on)

> When you have more than one service interacting, or when your LB restarts / fails over, what updates the DNS?

You can have the LBs communicate peer-to-peer so they can update DNS when they become unavailable (if A and B can't reach C, they remove its DNS record). Some care needs to be taken to prevent things like split brain but there's established patterns for cluster formation. Something like keepalived could be used. You can also use VIPs instead of DNS

You end up with service discovery either way. Either you discover a load balancer or you discover an endpoint directly. Load balancers allow you to more granularly route traffic with the client being aware of the server topology. This is good when you're exposing services to the web/public clients. On the other hand, load balancers add a certain overhead and can become bottlenecks for high-traffic services


> you can have the instances register themselves in DNS when they turn on. You can also have an out of band system register things in DNS based on rules (or maybe...

Yeah, don't do this. This is _exactly_ what the article is saying not to do. It's a nightmare to maintain, totally non standard.

> You can have the LBs communicate peer-to-peer so they can update DNS when they become unavailable <...>

Or you could use a system that doesn't require you to write custom P2P traffic for a solved problem. Doing this instead of using an existing system is an interesting decision.


Dns of LB stays as it is in both cases. Instances get registered and unregistered in LB by ECS Service. LB in AWS has redundancy built in.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...


See the authors reply about not taking this so literally. If you're using ECS, you're following the advice of the article.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: