(In all seriousness, I've been reading AWS launch posts for 20 years; this one was mainly imitating the S3 Files launch post but I diverged by adding the customer quote and the FAQ -- because of course I started this process with a PRFAQ, and some of the questions in the FAQ are legitimately important.)
I left 18 months ago, so my memory is a bit fuzzy, but there was at least an overall style guide, one for each post type (e.g. a launch announcement), and the style for procedures (inherited from AWS Docs).
Oh, I was being facetious. I'm pretty sure Jeff mentioned needing to spend time writing a style guide when he started having other Amazonians write posts for "his" blog.
I think its best usecase can be in agentic automation from what I can understand so far. I don't know if this is the correct read on the design choice; please correct me if I'm wrong.
If models/agents don't have to learn the various Route 53 & DNS API, and (with some guardrails) execute DNS jobs looking at it like a filesystem, it could make deployment automation quite simpler - and less prone to looping over wild esoteric solutions. (A year ago I asked Gemini about a Vertex deployment and it was a mess going through two dozen weird circus tricks - none that worked). FWIW a lot of the final knob pushes still require someone using a browser & clicking bunch of buttons. This simplifies it. "Everything is a file in UNIX" idea, but carried over to DNS & resource management
Are there that many people managing their dns by hand that they need this? Outside of various txt records, most of my domains are mapped to specific resources via automation.
But "automation" with this could legitimately (well, mostly) be based on a git repo with an s3files mount inside it. And a cron job, if you really want to get fancy.
This is... well it's mostly a joke. It's funny but you can indeed use and interact with DNS as a file store or have a file system based control over records.
Both DNS and S3 or any filesystem really... they're just key/value stores.
DNS also has considerably higher reliability and compatibility than almost anything else
Speaking as a former Blog Bar Raiser, cperciva has internalized the AWS blog style guide better than most Amazonians. This is spot-on.
Wait, there's an official style guide?
(In all seriousness, I've been reading AWS launch posts for 20 years; this one was mainly imitating the S3 Files launch post but I diverged by adding the customer quote and the FAQ -- because of course I started this process with a PRFAQ, and some of the questions in the FAQ are legitimately important.)
I left 18 months ago, so my memory is a bit fuzzy, but there was at least an overall style guide, one for each post type (e.g. a launch announcement), and the style for procedures (inherited from AWS Docs).
Oh, I was being facetious. I'm pretty sure Jeff mentioned needing to spend time writing a style guide when he started having other Amazonians write posts for "his" blog.
As a non-Amazonian I've never seen it, of course.
A “schema that reads like XML that learned JSON in prison” IM DEAD
Stealing this. Gold lies at the intersection of cperciva and quinnypig.
At first I thought this was a general purpose file system over R53, ala Corey Quinn. But my, what a gorgeously terrible idea. Well done.
to be fair, it's also that just with some severe restrictions on filenames
I think its best usecase can be in agentic automation from what I can understand so far. I don't know if this is the correct read on the design choice; please correct me if I'm wrong.
If models/agents don't have to learn the various Route 53 & DNS API, and (with some guardrails) execute DNS jobs looking at it like a filesystem, it could make deployment automation quite simpler - and less prone to looping over wild esoteric solutions. (A year ago I asked Gemini about a Vertex deployment and it was a mess going through two dozen weird circus tricks - none that worked). FWIW a lot of the final knob pushes still require someone using a browser & clicking bunch of buttons. This simplifies it. "Everything is a file in UNIX" idea, but carried over to DNS & resource management
Are there that many people managing their dns by hand that they need this? Outside of various txt records, most of my domains are mapped to specific resources via automation.
There are apparently many people managing their S3 Objects by hand but long to have them in a file system, yes.
I don't think this is there to satisfy "need".
But "automation" with this could legitimately (well, mostly) be based on a git repo with an s3files mount inside it. And a cron job, if you really want to get fancy.
Files which aren't DNS keys get ignored by Route 53 Files. So you could absolutely have a git checkout and update your DNS with 'git pull'.
Last job, we did for various control/audit reasons BUT it was all IaC and tickets.
This is... well it's mostly a joke. It's funny but you can indeed use and interact with DNS as a file store or have a file system based control over records.
Both DNS and S3 or any filesystem really... they're just key/value stores.
DNS also has considerably higher reliability and compatibility than almost anything else
> Are there that many people managing their dns by hand that they need this?
How many thousands or millions of employees does your org have?
[0]https://banner.triweb.dev [1]https://news.ycombinator.com/item?id=39502097
Am I the only one who thinks that read() and write () (block based api) would be a poorer experience for managing key/value dns records?