I’ve periodically made reference in a bunch of places to Route 53 being my preferred database.
Today is your lucky day!
Before I begin, I want to emphasize that this is tongue-in-cheek. Please do not do this.
There are, in 2020, far better ways to solve this problem.
DNS isn’t really a database
Many years ago, I worked at a company that looked a lot like a traditional on-premises build-out, because it was. Cloud was nascent in those days, and the 2008 financial collapse was yet to come. We had a bunch of virtual machines (VMs) that were themselves running on physical hosts in racks.
Everything you might expect of such an environment was true. We had cabling problems, we bled on the rack nuts, we drove at unsafe speeds in the middle of the night to frantically restore service when things broke.
As I said, it was a different time.
We had some limited ability to migrate VMs between physical hosts. Live migration didn’t work in our configuration, so these VMs tended to stay pretty much where we put them. This led to a series of problems that in hindsight were entirely avoidable.
Note to future self: You have two DNS resolvers for redundancy; perhaps do not put them both on the same physical host.
Which of course brings us to DNS.
We wanted to know in a hurry upon which host any given VM lived, so we struck upon a somewhat novel solution. DNS TXT records are a type of resource record in DNS that support arbitrary strings. They’re used for a variety of “validate you own the domain,” DMARC / SPF spam reduction systems, DNS-based service discovery, and other various use cases. Being the geniuses we were, we struck upon the idea of using these records to set each VM’s host VM.
From there, it didn’t take us too long to hit upon the idea that this worked super well with our sysadmin scripting language of choice: crappy shell scripts.
dig TXT vm1.web.prod.ord.twitterforpets.com returned a neat
defiant.prod.ord.twitterforpets.com answer. (We’ll save my “Federation Starships” server naming convention for another day.) Thus, it became super easy for us to work this into our crappy management scripts.
“Validate that the physical host has no more VMs on it BEFORE you yank the power cable out” stopped being a sticky note that got ignored. Instead, it became a script that was generally ignored instead until right after it really needed to have worked. “This VM seems slow, which host is it on?” was now a quick DNS query away. And times were good.
Of course, this is horrifying today.
Most environments have a control plane that can give you these answers in the form of metadata. It’s also close-to-but-not-the-most horrifying abuse of tagging possible in a cloud environment.
Functionally, what you’re really looking for is something like a configuration management database or something fairly robust like Device 42. Instead of twisting low-level primitives (not to mention yourself) in knots, use something that’s purpose-built for the task at hand.
Route 53 (Amazon’s managed DNS service) is the only AWS service with a public 100% SLA on the data plane. It incurs no charges for data transfer anywhere inside of AWS or out to the internet. As long as you move a hosted zone to either a new zone or a different AWS account within 12 hours, the 50¢ per month charge per zone doesn’t apply.
Route 53 is a database
I do declare that Route 53 is in fact a database.
There are libraries to make it more user-friendly to query. Every system, every language, and every SDK knows how to speak to it. It loses considerably less data than MongoDB. The pricing is reasonable even without weasel-tricks to get around it. And its underlying technology has been proven out over decades.
It provides “CA” on the CAP theorem conjoined triangle of success. It is, for the moment, non-relational. And it’s super hard to raise $2 billion in venture money from Softbank around a technology this unexciting.
All of that goes to show that DNS—and, by extension, Route 53—is not only a perfectly suitable database option, it’s the best database money can buy.
I dare you to prove me wrong.