3 ms·

What are you using instead? Hard coded IPs? Or have you built your own lookup service? If you have decent TTLs dns doesn’t result in a shitstorm of lookups, no

What are you using instead? Hard coded IPs? Or have you built your own lookup service? If you have decent TTLs dns doesn’t result in a shitstorm of lookups, nor does it require anything more powerful than a raspberry pi to respond to them

jovial_cavalier 3y ago
/etc/hosts ?
vinay_ys 3y ago
Yes, it is much easier to build and scale a general config service that can serve keys (like names in dns) and associated config snippets with versioning and expiry/go-live timestamps etc. Such a service enables us to build on top of it things like service discovery, failover, draining, cutover, weighted load-balancing etc. It is much easier to also control/orchestrate/audit changes to key-configs in globally consistent transactional manner and guarantee these changes will be instantly visible to every client or will be deterministically spread-out/staggered etc. It is also much easier to do interpolation of config variables arranged in a hierarchical class namespace. All this makes it a lot more powerful building block for large scale infra services than dns ever could and it has none of the drawbacks of dns.
- moondev 3y ago
  Now we just need a kubernetes cluster with coredns to deploy eureka! http://eureka-0.eureka.default.svc.cluster.local:eureka:8761/eureka http://eureka-1.eureka.default.svc.cluster.local:eureka:8761/eureka http://eureka-2.eureka.default.svc.cluster.local:eureka:8761/eureka
marcosdumay 3y ago
> If you have decent TTLs dns doesn’t result in a shitstorm of lookups, nor does it require anything more powerful than a raspberry pi to respond to them This applies equally to any kind of lookup service you use. It's not a distinguishing feature of DNS. The distinguishing features of DNS are that it's a global, highly regulated, key-value storage with only eventual consistency that may take days to reach. (It has probably never been consistent on practice.) None of those features are desirable for your internal servers configuration.

jovial_cavalier 3y ago

/etc/hosts ?

vinay_ys 3y ago

Yes, it is much easier to build and scale a general config service that can serve keys (like names in dns) and associated config snippets with versioning and expiry/go-live timestamps etc. Such a service enables us to build on top of it things like service discovery, failover, draining, cutover, weighted load-balancing etc. It is much easier to also control/orchestrate/audit changes to key-configs in globally consistent transactional manner and guarantee these changes will be instantly visible to every client or will be deterministically spread-out/staggered etc. It is also much easier to do interpolation of config variables arranged in a hierarchical class namespace. All this makes it a lot more powerful building block for large scale infra services than dns ever could and it has none of the drawbacks of dns.

moondev 3y ago
Now we just need a kubernetes cluster with coredns to deploy eureka! http://eureka-0.eureka.default.svc.cluster.local:eureka:8761/eureka http://eureka-1.eureka.default.svc.cluster.local:eureka:8761/eureka http://eureka-2.eureka.default.svc.cluster.local:eureka:8761/eureka

marcosdumay 3y ago

> If you have decent TTLs dns doesn’t result in a shitstorm of lookups, nor does it require anything more powerful than a raspberry pi to respond to them This applies equally to any kind of lookup service you use. It's not a distinguishing feature of DNS. The distinguishing features of DNS are that it's a global, highly regulated, key-value storage with only eventual consistency that may take days to reach. (It has probably never been consistent on practice.) None of those features are desirable for your internal servers configuration.