The problem with having a few running jokes in this newsletter is that if you weren't around when I came up with them (or, heaven forbid, you skipped an issue), they may not make much sense. Today we explore my Route 53 as a Database schtick.

As always, should you wish to link someone else to this post, you can forward it, or else view it on the web.

Sponsorships are fun sometimes.

ParkMyCloud: "Can we have one of our execs do a video chat with you?"

Me: "Better idea, how about I talk to one of your customers instead so we can make fun of you on your dime?"

It turns out I'm SUUUPER convincing, so that's what's happening! Join me and ParkMyCloud's customer Workfront TOMORROW for a no-holds-barred discussion about how they're optimizing AWS costs, and whatever other fights I can pick before ParkMyCloud realizes what's going on and kills the feed!

Register here to catch the fun. Sponsored

Route 53, Amazon's Premier Database

I've periodically made reference in a bunch of places to Route 53 being my preferred database.

But I've only really told the story in podcast and tweet thread form. I've never gone in depth as to how this terrible, terrible antipattern came to be in a blog post—which is far easier to cite.

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.

And yet...

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.

The world has been rife with misuses of DNS: serving as a tunnel, a filesystem, and a DDoS cannon, for example. As such, viewing it as a database isn't the strangest idea in the world.

And so...

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.

When using Amazon’s Elastic Kubernetes Service (EKS), you must understand which pieces of the security management role fall on you. Use this 42-page eBook from StackRox to learn about EKS cluster security, including the standard controls and best practices for minimizing the risk around cluster workloads, as well as specific requirements for securing an EKS cluster and its associated infrastructure. Sponsored