Launching Route 53 Files

(daemonology.net)

34 points | by louis-paul 1 hour ago

6 comments

  • dbarlett 30 minutes ago
    Speaking as a former Blog Bar Raiser, cperciva has internalized the AWS blog style guide better than most Amazonians. This is spot-on.
    • cperciva 26 minutes ago
      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.)

      • dbarlett 14 minutes ago
        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).
        • cperciva 9 minutes ago
          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.

  • mlhpdx 47 minutes ago
    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.
    • colechristensen 45 minutes ago
      to be fair, it's also that just with some severe restrictions on filenames
  • srvmshr 31 minutes ago
    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

  • ChiperSoft 1 hour ago
    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.
    • cperciva 1 hour ago
      There are apparently many people managing their S3 Objects by hand but long to have them in a file system, yes.
    • regularfry 58 minutes ago
      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.

      • cperciva 52 minutes ago
        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'.
    • stackskipton 40 minutes ago
      Last job, we did for various control/audit reasons BUT it was all IaC and tickets.
    • colechristensen 50 minutes ago
      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

    • esseph 1 hour ago
      > 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?

  • GuinansEyebrows 1 hour ago

        > Q. Is this HIPAA compliant?
        > A. Please do not store patient information in DNS.
    
    love this. reminds me a little of something else in the realm of DNS "hosting" posted to hn a few years ago [0][1]

    [0]https://banner.triweb.dev [1]https://news.ycombinator.com/item?id=39502097

  • tonymet 22 minutes ago
    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?