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

I advocate for using Route 53 as a database and even I think this is terrifying.


I'd say Route 53 is more of an eventual consistent object store rather than a database :-)


Out of curiosity how do you use a DNS service as a database?


Excellently. I use it as a database excellently: https://www.lastweekinaws.com/blog/route-53-amazons-premier-...


OOC, what are the downsides of storing service discovery information like this in TXT records? As opposed to using ZK, consul, etcd or a more standard solution?


There are better tools for the job now. This is basically a misuse of a service instead of using things that are purpose built.

I mean, your inventory is either a grep or a zone transfer this way, for one.


A zone transfer or grep really isn't so terrible, even for someone who doesn't know much about dns it's just a quick memorized dig away. HTTP or grpc aren't really better CLI UX and if this is your infra you can just write a cli to display your dns-driven information cleanly.

Storing key-value pairs in TXT records is easily parseable in any language if you use a simple delimiter. This isn't even an abuse of DNS, the protocol has been used to serve arbitrary data forever.

All the other modern services like consul, etcd, zk, etc require keeping a quorum of servers happy and have pretty heavy clients. By contrast, it's so hard to take down DNS and spinning up a new server is as easy as copying a zone file to a new server and the new server could even be running a totally different dns implementation because zone files are so standardized. Plus, your tooling can directly parse zone files with whatever dns library you were using and have a trivial way to dump the data without any server at all.

DNS can be replicated in arbitrary configurations and everything supports DNS caching for really high HA.

When you do want dynamic discovery and don't want to implement direct zone file generation, there's always CoreDNS which has plugins for so many datasources.

And if you don't want to host it, there are tons of DNS providers with great uptime.

At this point, I really can't think of any solution for service discovery that's better than DNS for most cases. Especially since the majority of service discovery solutions end up returning hostnames instead of IP addresses so you're already taking a dependency on DNS. Other solutions only really add benefit if you need to store tons of metadata or take advantage of things like leader election, etc


If only AWS Cloud Map wasn't $0.10/resource outside of ECS you could reasonably have your API cake and query it using DNS too.


What’s a good example of a better tool


You use text records and have a key value pair in a record.


You should totally fork juicedata to use your route53 technique. That would be rad.


I mean, kinda same, because my lizard brain still remembers getting burned - but in theory it's not much different than what Storage Gateway in File Gateway mode or Nasuni and others have been doing for years, is it?




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

Search: